Coding Blocks - Things to Know when Considering Multi-Tenant or Multi-Threaded Applications

Episode Date: September 2, 2024

It’s time to talk about the types of things you should consider when diving into multi-tenant applications and things to be especially aware of if you attempt to make things faster by going multi-threaded at the same time. Join us as Allen continues is non-winning / non-losing streak, JZ is taken out by a storm, […]

Is this 241? Did I write it right? Yeah, that's 241. Okay. All right. How are you going to do it this time? Outlaw? Well, I was going to say episode 242, but since you said that it is 241, I guess we're going to start with 241. So welcome to the show and we hope you enjoyed it and have a good day. And sorry about the off by one error they have wait i see what i did i got my show notes mixed up there where the intro and the okay so uh yeah so hey how you doing welcome to the show we're coding blocks sure i guess i mean if whatever you're

listening on we'll probably have more details if you want them and uh i guess we can keep it moving or if you don't want the details too like who needs details i give what's your name what is this trick they're just staring at it yeah it's awesome i'm alan underwood well you weren't even supposed to go first i wasn't expecting that that's why oh oh are you looking at the intro now is that what we're doing i think you're looking at the the exit notes yeah that's why oh oh are you looking at the intro now is that what we're doing i think you're looking at the the exit notes yeah that's that's the problem oh yeah so now we're gonna read the intro yeah no i'm i'm michael i'm joe zach and i'm alan underwood all right well we got any reviews i didn't realize we needed surnames too so yeah i'm michael outlaw from the top yeah yeah the one with the coolest surname

like how would you leave that off hey hey hey oh is that the better one my bad the two first names a lot of cool zacks in history is that morris and i mean who else do you need right zach attack uh that's amazing all right, we got, we got any reviews this time. Oh, you know what? I think that one's a mistake, isn't it? Uh,

I believe it is. Yes, it is. So it is. Yeah. So, uh, yes.

So 95 almost got a repeat, but I caught it. So I won't say that one live on air. Great. Great. Um, but column fairy, thank you very much. Uh, you left us a

review on another review this time on Spotify. So thank you very much for that. Excellent. Awesome. And as we've been mentioning, man, this is actually coming up really fast. Atlanta dev con is going to be here September 7th, 2024. Are you guys going? I think so. I need to check and see if I can. But yeah, so like a little more than a week, this is going to be upon us. So atldevcon.com, if you want to check that out and you're in the area.

So do you want to see if this call for speakers is still open? No, I think I'm good. We're sure it's not. Yeah, I'm good. DevFest Central Floor is also coming up September 28th, and that is also closed, but you should check it out. It's a really cool event. Give Javier a big what's up for me.

Oh, is he running that now? He's part of the group, puts it on. He's been doing a lot of promotion and stuff for it and does a fantastic job. I can't think of many more people who do more for the local community. That dude's awesome. He was awesome. We met him

when we went down there. Golly, he's been five, six years ago. Awesome guy. Awesome guy. Definitely go check that out if you're in the Orlando area. With that, let's get into some random topics that have been bouncing around. Hey, you got something. And I'm Michael Outlaw.

Awesome. Hey, you got any dad jokes for us? I think Ivan Kuchin was excited that we brought that back. Oh, well, I don't have – I can very quickly get one. The only one that comes to mind right off the top of my head, just because I was talking about this earlier is like, but I think we've already heard talked about this when you already know it. Uh, in fact,

I think we might've said it like last episode. Uh, what does a nosy pepper do? Uh, I don't know what it is, but I think we lost Jay Z. I believe his power went out. Like, seriously.

No, no, no. He's doing Bohemian Rhapsody. He's about to sing right now. This is the operatic part of the song. We should screenshot that. The answer is it gets jalapeno business. I don't remember that one, but that's pretty good. I could have sworn we did that one.

Okay. Maybe you did. How much does a hipster weigh? I don't know did that one. Okay. Maybe you did. How much does a hipster wear it? Way? Ooh, I don't know. An Instagram. That's pretty good. Hold on.

Let's check. I think Jay-Z wrote us here. No, I'll write in. I'm Joe Zach. He did lose power. All right. So he might be back here in a minute,

but we're going to carry on so that, uh, cause we don't know how long it's going. We've actually got a storm, uh, you know, between between the three of us like right over all our houses right now so yeah it's pretty interesting because like one of us will hear the thunder first and then the other and then the third well it's not anymore but yeah it's a garth brooks song the thunder rolls oh all right yeah yeah there we go not that you know who that is of course i know who that is everybody knows who garth brooks is you never listened to garth brooks

oh come on man i've got the greatest hits of course everybody everybody blaming all my roots i showed up in boots all right we're gonna go ahead and change the name of the show today that's amazing All right. We're going to go ahead and change the name of the show today. That's amazing. All right. The best part, though, is the faces I'm making as I was doing it. He's performing.

He's on stage. All right. So this one came up because I recently had something that I was working on. We have multi-tenant apps that we work on, right? So they're processing all kinds of stuff. And, and I need to do some things that were going to be asynchronous. So if, you know, whatever world you're living in, it could be in Kotlin, you're doing co-routines and whatnot. If you're in Java, you're doing threads. If you're in C sharp, you're doing probably async type stuff over there. So the big thing that I wanted to bring up is

async is incredibly powerful and useful when you need it. right? But there is a very good chance that if you don't understand what you're doing, that you can leak data across threads, right? So anytime that you have a shared object, specifically a shared object, if you don't know when you start doing async programming or threaded programming, that you need to lock that object

so that nothing else can get access to it while you're using it, you have a very good chance of having race conditions or leaking data from one thread to another. So I was curious what one of our AI friends would say about doing multi-tenanted applications. And so I asked Claude because I mentioned them as, or him or her as, as a tip of the week, a few episodes back. And my question was in the show notes and I assumed it was a listener or, you know,

someone in the Slack channel. And I'm like, Oh, Claude's pretty informative. Claude's good, yeah. Yeah, so the question that I asked Claude was, what are some things to consider when writing multi-tenant code? And it spit out a bunch of stuff.

And I figure we talk about a little bit of it here. And then it actually asked right after that, when we get to the end of this list here, it asked, hey, would you like me to elaborate on any one of these points or discuss specific implementation strategies? Which is cool. You could have just replied, yeah, I'd like more information on number six, right? And then it would have done it. So pretty well done.

I use ChatGPT quite a bit. I use Gemini quite a bit, which is the Google one. And then I've been using Cloud as well. And I do find Cloud to be really, really good. So the first thing that it says is data isolation. Ensure that each tenant's data is securely separated and inaccessible to other tenants. It seems reasonable. know, reasonable. Good thing.

Yeah, right. Authentication and authorization. Implement robust systems to verify tenant identity and control access to resources. Okay, again, yeah, that seems legit. Seems common sense, I guess, these first two. Yeah, I was going to say, like, I'm glad you said it, because I was like, I don't think I'm getting a lot of value out of cloud here.

Yeah. Not so far, not so far scalability. Now this is what I can get on board with. Everything's got to go to a billion. So design the architecture to handle growth in both the number of tenants and the data volume per tenant. This one I find interesting now law because we've done this in the past, like legit, not just my babillion logins or whatever. You can overdo things up front, right? Like if you're, if you're trying to anticipate that

you're going to grow to so many things and you need to charge your databases and like, you can create something so incredibly complex up front before you even have the first five tenants in there that may come back to bite you. And I'm curious what your thoughts on that. Should you overbuild from the beginning or should you build it to where it works great until you start running into some issues and then you figure out what to do from there? Man, this bleeds into something that I want to talk about so badly later that I had in the block later, but I would, I would say to answer your question that I would not try to like over architect from the beginning,

right? Because a lot of that's gold plating. You don't know what's going to be needed until you get to it. And I think like, I was thinking about this over the past week or so that of all the books that we've read and everything, and especially of the Uncle Bob series of books that we've read. I think that one of the most valuable takeaways that I've gotten from that man is procrastination. Like just put off decisions until you, you know, and then by the time you're,

you have to make the decision, you will have much more information. You'll be able to make a better informed decision. So yeah, I wouldn't go, you know, spending like a whole bunch of time architecting, like,

you know, before getting into, I would start, I don't know, maybe somebody would argue with me about why you shouldn't like, you know, before getting into, I would start, I don't know, maybe somebody would argue with me about why you shouldn't like just start coding, but that's not to say to take things into consider, to not take things into consideration, you know, especially in like a multi-tenant type of, uh, world and where you are doing multiple threads and whatnot. But

I mean, yeah, sure. Think, you know, be considerate of that kind of, those kind of like problems that you have to solve for in your workflow. Sure. So I'm a hundred percent on board with what you just said right there. I think that, and by, I think what you said by not over architecting, I'd say

also not over implementing, right? Like I would actually be more okay with, with spending a ton of design time up front to say, Hey, this is like what we think the perfect scenario would be. And then also design a few others and say, Hey, I think this middle road is where we want to get to and then start implementing that. I love that because I've seen it. I've seen it several times in my career that you go into something thinking, oh, I know exactly what we need to do to make this thing scale to however many we need it to. And then when you get in there, you find out one, you miss some things because you can't know everything. And two, there's problems with what you overdid in the beginning. And then so now you're fighting two problems, right? Now you're fighting the, I need to scale better and we forgot this one thing.

And now there's problems with this other infrastructure thing we did. Now you're fighting two wars, right? And that's a problem. Yeah, or the assumptions that you made in the beginning. Like you might have thought like, oh, I think this is going to be a big problem so we should solve for this and then it turns out that's not but the thing that you didn't think of turns out to be the bigger of the problem so yeah for sure man so jay-z's back with us uh apparently he was recording some conversations with his dog while we're while while he was away. I think my singing broke his internet. I didn't even hear that. Yeah. You're

in for a treat, man. You're in for a treat or, or are you, Hey, it was, it was pretty good. I'm going to, I'm going to throw that out there. That's a high compliment right there. Hey, it was a thousand times better than what i could have done so you know i was impressed man i didn't expect him to be belting out garth brooks so well and accurately garth brooks man yeah yeah and he knew the words he knew the words to probably one of the more obscure songs that he would have had out there so Deep cut, no way. That's got to be one of his number one hits. Come on. Friends in Low Places?

Okay, we can't go on with this show. This topic is done. I'm sorry, welcome to the Garth Brooks hour. Yeah, you're probably right. Look, I can name probably 12 Garth Brooks songs and that's not one of them. Never heard of that before.'s like thunder rolls the dance uh yeah right uh yeah there's a standing outside the fire yeah there's so many good ones right

like you got the greatest hit so yeah we could do this all day um all right so the next one that clog came up with was performance. Now I will say one thing that I noticed with a lot of what that came through in their answers seem to be database related, which I thought was interesting. But performance optimized database queries and resources allocation and resource allocation to maintain speed as tenant count increases. Again, seems like common sense. I think that's, I think that's something more that you do as you go though, right? Like sort of like what outlaw and I were just talking about. Don't try and over optimize in the beginning. Um, customization allow for tenant

specific configurations and features without compromising the core code base. I actually liked this one because I have seen this go sideways several times over my career where, you know, you have, you have customers, but then you have the big customer, right? And that big customer is always asking for changes. Or maybe, maybe you even have just the noisy neighbor customer, the one that wants all the features in the world. And instead of doing things, um, right ish, you'll find ways to hack things into the code base. And now you have all this branching logic for what's supposed to be this core code that is now like just nasty and it's spaghetti code because you've tried to make all these exceptions for people. So I like this one.

I viewed that as, I thought you were going someplace different. I viewed that as like the, the big, the big one being the whale. I mean, like that's the one that's like, you know, really heavily invested into your product,

paying a lot or whatever. And then the chatty is the one that like, regardless of what they're paying, like they're the ones that are just hammering your APIs. Right. Or, you know, like, Oh, things are slow because that you know and allowing for either of those type of situations like especially the chatty one to where like your workflow can handle like that chatty data that

chatty traffic without it interfering with other tenants, you know, like how do you, how do you, how do you, uh, dynamically and smartly decide when it's time to like segregate that off to, you know,

uh, different shards, different servers, whatever the, you know, the case might be for your, your use case. But,

you know, that's a a whole other level of involvement that you can go down there. But when you can drive that by config, let's say it's a Kafka kind of situation. Maybe if you had, oh, well, the 98% of traffic is going to go to this cluster over here because whatever. But there's these couple there, especially chatty, and maybe they need higher retention on their topics because of the amount that's coming in. It might take like a minute longer to process or whatever the case may be. And you just, by configuration, you're like, okay, that traffic goes over there

because they are the noisy neighbor kind of problem, and I'm going to segregate that traffic off to its own set of servers that are specially configured for that type of throughput. I like that. Hey, and Jay-Z, to catch you back up, because I think you missed the opening to this. The thing was, hey, when you're writing multi-tenant code, what are the things to consider? And so I this a while back, and I was like, that's weird. It's almost the same bullet points. Does this come from a person named Claude in the chat or something?

That's wow. That's funny. The thing that I was describing basically, though, is essentially like we've talked about in the past where Twitter had documented their architecture and the problems you know, years ago that they were solving for. And you remember how like the, the fan out of a user who had like a lot of followers or that was followed by a lot of people like to create their, you know, their, their homepage for them to see their feed was a much different type of problem than to go and get your mom's feed to get her

to load up her Twitter homepage for her to see her feed because she's maybe has only her son as a follower but is following her 20 favorite celebrities or something like that. her feed because she's like you know maybe has only her son as a follower but you know hat is following like her 20 favorite celebrities or something like that right like they were drastically different problems yeah i think uh designing data intensive applications even touched on twitter specifically for that because of the data storage stuff so um the next one up here is i think we could all agree just hyper important is monitoring and logging. So implement comprehensive logging and monitoring to track usage errors and performance

per tenant. That's probably massively huge to have in place. Um, maintenance and updates, design system to allow for updates. Okay. That fine, that's fine. With minimal interruption to tenants. Now, depending on technologies, this could either be really easy or really hard. Like if you go the Kubernetes way, they have all kinds of things in place to help you out with that if you take advantage of them. So definitely using orchestration systems should make that easier. I think even Puppet, if you have something that's more bespoke, that's not necessarily something like Kubernetes, there's tools out there like Puppet and Chef that also help with this kind of thing.

Yeah, like Helm has support for rolling updates. Yep. I mean, those types of things can save your bacon, right? And make it to where there's very little impact on the customer. Data backup and recovery, that makes sense. Compliance and data regulations, that's probably more important now than it ever has been, right, with GDPR and all that kind of stuff now. So that's probably a big one. And then tenant onboarding and offboarding, they say create

efficient processes for adding new tenants and removing old ones. That's actually a really good point that I don't know that if I was just thinking through this list, I necessarily would processes for adding new tenants and removing old ones. I, that's actually a really good point that I don't know that if I was just thinking through this list, I necessarily would have put in there, but I think that's huge. Like making it easy to, to bring something into the system and also clean things out of the system when, when they're done, right? Like that's a, that's a pretty big thing. And so you're always having to think about almost like roll back and roll forward type scenarios with these things. Like, hey, if a tenant just wants out, okay, how do you hit the delete button and it just disappears from everywhere?

And I think you looked at adding something there, Jay-Z. Yeah, I was just trying to think. I couldn't find my notes on what I did before, but like one thing I remember from it was just good feature flagging support. Like if you just have kind of basic feature flagging, like something is on or off for the app, then you lose some flexibility when it comes to certain tenants.

Sometimes you want tenants to get features early if you're working with them or beta testing or whatever. And so you want to be able to kind of have more fine grained stuff at like the tenant level for that so i think it's good to spend some time thinking about feature flagging in a way that's you know built in better than you having a bunch of ifs or something like if tenant equals whatever agreed i like that or even if feature on or off generically yeah like is the feature on or off for the specific tenant right you're getting at yeah exactly um another thing that they missed up there that i think we would probably all agree is

really important is that goes along with the monitoring and logging and we did a whole series on this you know several months back is alerting you know it's great to have logs it's great to have monitors in place and graphs and charts and all that stuff but you really need to be alerted when when things aren't happening the way you think they should right like data didn't make it from point a to point g okay i need to know that that that that didn't happen that there's a process broken somewhere so that's big so what's funny is after we got to the end, go ahead. You, I got distracted. I had a family thing.

You said, what was the thing? Alerting. Okay. So, cause the one that I thought you were going with would be, um, uh, traceability.

Like, uh, there's a better word for it. There's a better word for it. What am I talking about? I think you actually are talking about tracing. It is like a Jaeger or open telemetry, like that type of thing where you can see like this specifically for this tenant,

like what happened. How it flowed. Yeah. I mean, one thing if you're living in a distributed world, which if you're working on multi-tenant apps, it's a pretty good assumption that you're working on multi-tenant apps it's it's it's a pretty good assumption that you're working on a distributed app of some sort right like something that's likely not installed on prem but well that's why i'm not always if it's a if it's a multi-tenant

app we're probably talking about something big like yes exactly so yeah i think that's fair to make that assumption that there's like multiple parts to this puzzle in play. So that whole thing about logging and especially logging what Outlaw just brought up is that, and we did a whole series on open telemetry as well, is knowing when a request came in and how it flowed through the system is so powerful as opposed to going in and being like, okay, well, I know that, you know, the web, the web app called this server and then this server called this thing. And then that called that. And then you having to go and chase it down yourself versus being able to be like, all right, here was a request. And this is how it flowed through the entire system. Right. In one block. That's a, that is so powerful. Yeah. I mean, the monitoring and logging in one block that's that is so powerful yeah i mean the monitoring and logging was one of the ones in here but i kind of feel like tracing is is beyond

logging though like for sure it's like logging on steroids yeah it's it's logging plus plus i turned it off so all right sorry about. Sorry about that. All right. So, so the next one, the next one up that I had in here was actually the response to the, Hey, do you want to know more about this? So the very first thing that it said was data isolation. And I was like,

okay, well, let's see what it says about this. So I said, Hey, could you tell me a little bit more about data isolation? And this is definitely the more you can get, the better I got. So i see this starts in with like

separate databases but i've seen people take it even further and like separate uh cloud accounts like if you're you're running a cloud app like actually having like a whole separate um not even project but just like set of credentials of the logins like a whole separate shebang okay i take i take issue with that being like a blanket recommendation, though. Because depending on your company, what you can afford, what your customers are willing to tolerate in terms of price that you can charge from them, and how many customers, the type of customers, the type of business you're even solving, like you to go completely isolated and separate like that, like you might be losing economies of scale that. Yeah, sure. That sounds great. If that level of isolation is what you need, like I could think like government projects would would probably want something like that. Right. projects would would probably want something like that right but if it's not like hyper sensitive or necessary that it'd be separated like that like you know maybe you can take

advantage of some economies of scale and save a buck you know yeah i mean there's definitely a trade-off there but uh there are companies that do it like so for example we've talked about like elastic and kafka both having like managed solutions for the products and both of them have the ability to kind to bring your own cloud. So they'll deploy their stuff to your environment. You provide the access. So that's the kind of stuff I'm talking about. You can imagine a situation where you say, we'll deploy our databases.

We'll deploy all the stuff that we need wherever you tell us, for example. Or you pick the cloud or whatever. We'll put your stuff in there. But absolutely, you're going to be trading off uh some some costs there there's going to be costs and then and then there's also whether or not your application needs it right like if if you're storing super highly sensitive information sure but i mean if you're creating something i mean just throwing something off the top of my head here like baseball let's say that you create some sort of baseball application and you want different teams to be able to sign up for it. And your little kid,

Billy is moving around from place to place. It might be that you want to see his stats across everywhere, or you might want to see his stats compared to all the other kids of his age group. So there's reasons, I guess what I'm getting at is there's business reasons that you may not segregate things so tightly in that manner, to Outlaw's point. But if you're dealing with highly sensitive information, then maybe you want to lean heavily towards totally separate databases, totally separate logins, that kind of thing. It's a case-by-case basis. That's where the government option kind of comes in. Government contracts tend to be a little bit more specific about that sort of thing. But like the example that was running through my mind was like, okay, picture how many businesses use something like a Facebook or an Instagram or a Twitter expected to spin up a separate set of servers and databases for that business so that they like it's an it's it's not necessary so like

for claude to make this blanket recommendation i'm like it's a consideration for sure for sure for sure and depending on the use case and like anything that we've ever said on this show it it is always caveated with, you know, it's probably the right call 90% of the time or whatever. So, and I wouldn't even say that using a separate database is a 90% of the time thing. It's literally, hey, what's my use case? Does this make sense to do this way? Because it also adds a lot of complexity, right?

So, but they do point out that hey when you have separate databases like you use a separate database for each tenant then you have very strong isolation um you can set up credentials for each one of those things um i was about to say like wait a minute hold on stronger isolation easier compliance not necessarily depends on what you're doing for the authentication for that right if you use the same admin database or password for that, they're like, it doesn't matter. Who cares? Right. Like you can, you totally could, right? Like you can have your entire server and it has access to everything, which is a bad practice. So if you have a separate database, not encrypted, or they all use the same encryption key or, you know, or whatever, like,

you know, they're there, even though you might think like, oh, but encryption key or, you know, or whatever, like, you know, they're there, even though you might think like, oh, but it's separate, but that, yeah, but that doesn't necessarily, that's not an automatic buy-in for sure. For sure. Um, I, an example, a dumb example. Uh, so, you know, we've been talking about, I've been doing the redoing the wifi here slowly, uh, and trying to get things onto a more secured or segregated type thing. Well, I bought a router at like an actual router, not, not like the things that are the wifi mesh things. And dude is so complicated. And like one of the first things that they have is steps to, um, harden your router to make sure that people aren't able to get into it and all

that kind of stuff. And I'm like, okay, yeah, this is, this is a new level, right? Like you go buy an Orbi or something off the shelf. They're like, change your password. That's it. You know, this thing is, Hey, follow these steps to get there. And it's the same type thing. If you go set up a database server that you're going to be running a bunch of tenants on, you probably need to have more than the surface level.

I created a database, you know? Oh, and so some of the cons, higher maintenance, higher costs, potentially higher costs. I don't even know why they put the word potentially in there. It's higher costs. Um, well, is it, I mean, a lot of times it will be because you're, even if it's nominal, you still got more objects, right? You've got, you got more things that are being maintained across. You're going to have the same lookup tables and a lot of them, that kind of thing. So, so it may not even be a lot, but it will cost more, more than likely. Well, if it's separate database, it wouldn't matter if it's the same lookup table because they would be, they would each have their own copy. That's what I'm saying. So you're going

to be paying for more storage at that point, which again, it may not even be much, but chances are you paying more. Let's say, um, strong isolation is like, yeah, you could also say like strong security.

So the chances of you getting something wrong are, are much lower. If you are, you know, that's not the right way to say it. If the only thing you have to get right is choosing this account or that account, like kind of a top level.

And then there's no other kind of code decisions there's no multiple systems that you know everything else kind of flows from there then it vastly reduces the number of things you have to get right compared to like a multi-tint system where you're you know your customer is a row in a database essentially and then anywhere you're dealing with like application level stuff you need to have application level checks and it can you know one little error there and like a, you know, there's, there's a bunch of different ways to make errors. Right. But it can really swizzle the data and get things into a really bad state. And sometimes like even one misstep is catastrophic, you know, depending on the industry you're in.

Agreed. So you're basically putting the onus on the software you're running it on versus the onus on you getting it right. If you, if you do it a more homegrown way, which, you know, it's usually a better bet that they're going to get it right. Cause there's, there's tons of people working on that stuff, trying to ensure that doesn't mean there's not ever a problem with it. Right. But it is more unlikely. So then the next thing that they say, and again, they lean real heavy on databases here, which I thought was interesting. I guess it's still the center of most of the world for data, but shared databases with separate schemas. So that's interesting. That's

a way you could go. Each tenant gets their own schema with a shared database i don't love this one as much personally like even as a middle ground i don't know what you guys think this is this is where you're trying to get some economies of scale by saying like the lookup tables for example you could have one lookup table that's shared across all of the others by all the other schemas, but each customer could have their own schema where their data is separate and using a row-level security. Well, maybe not row-level security, but based on your credentials,

you could be restricted to what schemas you can look at. Right. But the problem with this one, though, is that both the both the separate database, completely separate database and the separate schemas version, the ability to maintain those databases, like when you want to whatever your strategy is for rolling out database updates, right? Like, you know, migration scripts or whatever you're using. You know, if you have separate databases, you have to run that migration script, you know, for every single customer independently. If you're doing it at a schema level per tenant, then, you know. It's close to the same.

Yeah, except you could also get into some, like, order of operation kind of things. Like, if you had computed columns that might rely on a shared, you know, table, then you could be in, like, real trouble. Yeah, I don't know. It gets complicated. it would just be problematic. Yeah. It's funny that the migrations thing, if you don't bring that up, it's easy to look at it and be like, Oh, this wouldn't be too bad. But when you start thinking about things like that, like, you know, I need to upgrade this or I need to do that. And that's another thing. So even, even get away from your own application migrations. If there's a major update, you know, like whatever, whatever database server you're on, they're like, well, we're deprecating support for this. You know, three months out. Now you need to upgrade everything. How's that going to go? Oh, you have a thousand tenants. Oh, that should be fun. Right? Like there's definitely some overhead to doing things

the most isolated way. And those are things you have to weigh. Maybe it's worth it. Maybe that is the only way, but it needs to be considered. So yeah, even with the schemas that say good isolation, more cost effective than the totally separate databases uh the cons requires careful access controls and potential for errors right like if you screw up some sort of shared thing uh across the schemas or whatever that can totally bite you um and then so here's here's another way and this is probably the would you guys say easiest way maybe this is basically where you have one schema you have one schema in the database meaning meaning you just have one set of tables but every single table has a tenant id in it right so so that you part you're partitioning the table by that column,

by that, whatever that column is. Yeah. Right. And so what they say is say what kind of partitioning? I mean, like there's like some databases have like harder definitions, like what partitioning means, like that you may also consider,

but yeah, well, you're partitioning data by it, whether or not the database technically supports partitioning by it or not. It may be a different thing, but, but you're basically saying the data in this table you know even though there's 100 tenants in it uh each tenant has its own and it's all based off that one key right you better never forget it forget a tenant id right right no doubt um so here's the interesting thing about this it It's the most cost effective, easiest to maintain.

They say, I don't know that that's absolutely true. And this kind of goes back to one of the things that I think outlaw and I sort of belabored a little bit earlier on the, on the performance thing. Like if you have tables that have large numbers of rows in it that are all partitioned by, by a tenant, then you have to think about performance things here. And that can actually be a pain in the butt to maintain over time, making sure that things are actually working properly. But then the other thing that they say, and this is true as a con, is it's one of the highest risks of data leak, right? Because

now it is on you to make sure that you have the proper like row level security in the database, assuming it supports it. And then in your application, ensuring that you don't somehow leak data across those things, right? Because now that you're in one database, depending on the authentication and authorization controls that are in place, you might only have that one log into the database, like what Outlaw was talking about earlier. And now you're controlling everything at application level, right? So said another way, here's the toss up between these options. Separate database means you only have to get the authentication right one time, right? If you can authenticate to the database and you get the correct authentication, then boom, everything else is

gravy. Going to the other extreme where you have one database, but it's multi-tenant, you have to have authentication and separation of data right every time. Like every time that has to be right. And the multiple schemas is somewhere in the middle there where, yes, you have to have the authentication right, and you have to have the data separation right, but it's a little bit worse because you could make the decision like, oh, well, this table could go in the shared schema, right? So it makes it

it's muddy um yeah you you you give yourself that kind of risk of like hey there's this there's this common area kind of thing you know and that in that scenario assuming you you like you know go with a common area for like lookup tables and things like that but you know maybe maybe you don't go that route but yeah that that's the problem is that like you have to with a single database but partitioned by tenant you have to have it right every single time and it requires careful you know consideration And this is like one of those places to where like, this is one of those times where having like making use of things like routines or stored procedures, you know, something like that can, in my opinion, help make it easier

to have like one place to like, look, you know, like, you know, I don't allow any developers to just write random queries against this database. You have to go through a routine because I want to make sure that that routine adheres to our, um, row level security or, or like, um, you know, includes that tenant in its, in its, as part of the predicate, right? It's, it's interesting. Um, so like databases, the popular databases are, or the probably most used ones, the Postgres is the SQL servers, the Oracle's those they have our level security, right? And that'll save you from a lot of things. Could save you from yourself. However, we've talked about this in the past.

One of the reasons why I think even the three of us eventually looked at it, that we'd rather write code that accesses a database from application tiers is because it's more testable. It's more enforceable there. There's more tools around doing things right in the application way than there are stored in the database. So it's truly a trade-off at that point, right? You really have to be careful if you go the route of having multiple tenants

in a single database. It's hard. Yeah. What I meant by that is if you have like one routine for getting tenant data that I don't care what library, what code, what language you're writing your code in, like you call that routine and it's on automatically apply in you know the the um as part of a predicate you know like a tenant information or something like that or like whatever your depends on like how your your database system handles that kind of real level security like if it's applied automatically or whatnot um you know but if it's assuming that it's not and if it needed to be applied

then if you do it that routine way, then you don't care. Otherwise, you could have like everyone, you know, writing like 15 different ways to do the same thing, which I mean, that's already kind of like that's not ideal necessarily, especially if like one of them got it really good and someone else got it really bad. Right. In terms of like, you know, terms of reading every row in the table or something. I looked at me when you said that. Well, yeah. I mean, I didn't mean to, but now that we brought it up, we're talking about this PR. But you know what I'm saying, though? you got to trust it puts a level of trust on like everyone else who's doing it who's writing those custom queries to do it and everyone who reviews that code to have like a keen eye to be like oh

wait a minute hold on you let me make sure that you're you're doing this in a tenant safe way yeah yeah i'm i'm torn on it i don't know if i love keeping everything straight in the database versus the application tier um there there definitely are the benefits you're talking about right like no question there are it's it's the age old this is this is like a tabs versus spaces kind of discussion almost really like you know but i'm just saying like in my mind there are times where it makes, there should be data access rules for sure. And there are times where like, it makes sense for those rules to exist as close as to the, as possible to the data.

So I'll tell you where this sort of crumbles a little bit. And this goes into the way Instagram ended up having to do things. And even, I think we even talked about it back in the day when we're looking at Postgres where you could short it, right? All of a sudden stored products may not be the answer because it's not necessarily on that same server,

right? Like there's, there's multi servers out there and you may not be able to access it through store products. And then you're back at the application tier anyways. So it's, it's really, I guess.

Well, in that example though, you're not at the application tier anyways. So it's really, I guess, the whole reason. Well, in that example, though, you're not talking about like a traditional SQL database there, right? Like I was thinking of like SQL. No, it's a sharded database. Yeah, sharded database. So like you remember, I can't remember the Citus. Was it Citus was the name of it? Yeah, for the SQL.

Yeah, Postgres. Yeah. Yeah, so it would actually shard out to potentially other servers, right? Have databases running on multiple servers so that when you needed to scale out, it would do that. And so now it is a traditional database, but the way that they performance scaled it was they basically broke things up and slid them out with application logic. So again, we're just throwing out devil's advocate and things on both sides of it. I'm totally not against putting things in the database, but just know if you choose to go the route where you're putting everything in a single place and you have a multi-tenant application, you better think really hard about how you're going to put those controls

in place to make sure that that data doesn't leak out. And it's the hardest thing to get right. And it's the easiest thing to screw up. Yeah. And it can make a lot of, it can have a lot of ramifications on, on you down the road for sure. Yeah.

Another thing that, Oh, go ahead. I was just going to say, I included a link to a site. situs if they if no one's ever looked at it before and you are in a postgres world situsdata.com it's just an extension to postgres that adds in the ability to um shard the tables and it was bought by microsoft i believe that is correct looking at it. Yeah. Yep. Okay.

Another thing to consider, and this is actually very important depending on how sensitive the data is, is encryption. So whether or not you encrypt data going in or whether it's sitting at rest. And if you've never heard those terms before, there's different ways you can think about data that are coming into your system, right? So if you imagine somebody opens up your table and can look in your table, is it okay if they can see the data in there, right? If that's the case that they can see the data in there, then you didn't store the data encrypted in your database. On the flip side, you probably want, especially if you're doing multi-tenant data to have that data encrypted at rest, meaning that even though you can read it out of the table, just fine. When it's on disc, if somebody were to take that disc out of the machine and take off with it,

they couldn't do anything with it. They wouldn't be able to read any of the data on it. It's going to be complete garbage. So you probably want to know about both of those things when you're, when you're designing your storage for tenant-level data. Oh, this one's good. Encrypt sensitive data potentially using tenant-specific keys. Man, that's a whole other topic. Yeah, it's pretty simple. You just create another key, and you're like encrypt oh x to y and then you know done

i know more about this than i ever wanted to um one thing is one key is it say what it's never just one key no it's never one key so if if you ever do have to get into this and start looking to it just remember the term envelope encryption, look that up and go look at how you should do that. One thing I do find interesting with this is know that there are tools out there like a vault. We've talked about HashiCorp vault before vaults really cool. And if you're, if you're trying to encrypt small bits of data, like not huge chunks of data, vault can actually do it for you. So you could actually have like tenant specific keys in a vault database, and then you can send it data and say,

Hey, for this tenant, I want this data encrypted for this particular tenant, and it will handle it for you. And it will audit log it for you, which is awesome. Where you run into problems is, is all of a sudden somebody is like, well, I have a one gigabyte file that I want encrypted. And what are you going to do? You're going to HTTP that thing over to Vault and then let it in. So you have to know the use cases, but just know there are tools out there for helping you do this and helping you do it right. Let's see. Extra layer of protection.

Connection pooling. Again, they're very hard on the database thing like leaning heavy into it um use separate connection pools for each tenant to prevent session mix-ups that's a really good tip honestly if if you're doing this have each have each tenant have its own session pool um query filtering uh i'll let one of you guys talk. Yeah, just the idea here is that you may want to kind of build some stuff at a low level if you are doing kind of queries

that mix tenants in a database. You are going to want to keep that as close to the data as possible. So for example, like each person writing a query for whatever they're doing doesn't have to keep remembering to add that tenant ID. You want to have some sort of like higher, lower level construct that's going to automatically kind of add that stuff in for you. Or it's automatically going to pick the right database for you.

So that's another kind of thing that you have to remember to make. Can you imagine like you get some sort of web controller or something and like every single call is like, all right, get the tenant. Now add the tenant to the where clause. Now go find, you know, it's like, oh, no, somebody's going to forget. It's going to be terrible. You need to really build that stuff in and have it just tested really, really well. This is consistent with what I was talking about before, where like, if you do have to rely on adding that to the predicate, then you would, in my mind, it makes it easier if you keep that as like, you know, you're only using store procedures or routines or something like that.

You know, it just makes it a little bit, you know, because it's closer to the source, right? To be able to have that happen. But I think if you can use something like a row level security where based on your authentication then that's even better because then that is automatically done for you based on your you know connectivity and yeah that that was actually something i was going to bring up a little bit later but we've talked about it a few times the authentication is going to be based on whoever's logged into the system, right? So you're going to have to have another good way to store those credentials for how that database is accessed, right, based off whoever logged in.

If it's Outlaw's tenant, then when he logs in, then the application needs to go correctly, grab the credentials for Outlaw, his tenant, and connect to his database properly. So that's why I say it's no big deal to encrypt it. Cause you're going to have the keys right next to the authentication. Fine. That's right. It's simple. Yeah. Just store it, just store it in the database with it. Don't at home. So I mean, Oh, that's a bad idea. So that's, that's one thing, But then also, so like what Al was saying is absolutely true.

If you can control it through proxy and do it, if you're not going to do it through proxy, you should probably have some sort of data access layer that only a few people even have access to mess with. And then everybody else can build on top of it, right? So anytime somebody wants to issue a query to the database, if they're not going to be doing it from a proc, they've got to do it through this data access layer. And they don't even have access to the code that goes and grabs the stuff that's going to enforce the row level security, right?

Keep the hands off of the most important part of it for the most part. So that would be my thing. Yeah, totally. And then, of course, any sort of API and application level checks need to be strictly enforced. And you've got to do everything you can there to kind of make sure that you're doing the right stuff. And so that's kind of where we say like the more you can kind of push that out of your hands, the better. But you know, there are cases where you have to do stuff like, for example, even in the case where you're like

creating separate customer clouds or whatever, inserting to their clouds, like the places that do touch that stuff have to be super careful and you have to have really good RBAC, for example, and role-based security around those checks and access control lists and just make sure that you get all of that exactly right because you don't want to mix up the data. You also don't want tenants to be able to poke around and access somebody else's database somehow or somebody else's cloud's cloud or whatever all that stuff is just really really bad i do i do want to like just because if anybody heard that term for the first time you said our back and then said role-based security but

technically the it would be role-based access control but it is the security but i just wanted to like clarify that for somebody that might be hearing that for the first time. They do say in here that you should use ORMs or query builders that automatically add tenant filters. I kind of disagree with this to a certain extent, because if you're using an off-the-shelf ORM, then a lot is left up to you to do right. And that's why I was saying, I'm not against ORMs. I actually like them, but if you're doing something in a multi-tenant way, like I said, you need to have sort of like this middle tier that you don't even control that, that somebody else manages and all your stuff is flowing through that just to ensure that, that anything that hits that database is almost guaranteed to lock down to that proper tenant. So, well, this is why I like,

man, not, not to beat on this one too much routine, but, but if you were, if you needed to add this as part of your predicate, right. And you did go the routine store procedure route, that tenant ID could just be like a required parameter. And if you don't

supply it, then it fails. You don't even return anything, right? Like you can't even call it. That's true. But on the flip side, if you're doing row level security, you don't even need that. Yeah. Because row level security is going to use the actual credentials that logged in and lock everything down to it, which is the best of all worlds. But in this example, though, the recommendation here was a ORM or query builder that automatically adds the tenant filters. I don't like it. Which assumes then that you have to add it to the predicate. And that's why I'm saying that, like, well, if you have this agreement on the team that, like, you only go through the routines and the routines require a tenant ID, then you can't even call the routine.

Yeah, I agree. I don't like that one at all. Yeah. But obviously, we agree, row-level security would be better. Yeah, it is the safest. Yes. Validate tenant ID in all API calls and application logic. I think that's almost a given.

If you're going down this road, you really need to and figure out some way to do it. If you don't know how to do it, I believe, I know Jay-Z frequents it probably more than I do, but OWASP typically has information on good ways to do this kind of stuff to ensure that the API calls are getting what they expect and all that. Yeah. Yeah, and OWASP does have a, they did start a project for multi-tenancy and kind of guidelines and stuff, but it hasn't gotten very far.

But I'm hoping that they keep at it. It's a pretty new initiative of FireColumn, Googling it right now. This is where I loved the attribute form of aspects to where you could say like you know require blah blah blah like you could have you could you could decorate you could write your your method but you could kind of decorate it with attributes to say like what's required and then those attributes would could do that kind of enforcement, right? Like require, require authentication, right? Before you can even get into it, right? So if you're not authenticated, then it automatically redirects you

to a login page. And if that's successful, then you can come back kind of situation, right? Right. And then the last thing that they had here was exactly what I was saying a little while ago, I guess I should have read the last bullet point, was the implement middleware to enforce tenant-specific access, right? So any code that you're doing is actually going through this middle piece to ensure that nothing gets there without the proper things in place. So what it didn't spit out, again, this was all very database-specific, and I don't know, Jay-Z, did you find the thing that you were looking for? Yeah, it's very minimal. It's just the incubator project. There's like no information

out about it. It's a really hard topic. It seriously is if you ever go to implement this stuff. So what I wanted to bring up that we don't even have in the notes yet was to just sort of spitball this a little bit is that's all fine and dandy. We're talking about where the data is stored. Okay. Let's talk about getting data in there. Right? So let's, let's say that you have some sort of pipeline where data is flowing through. Do you need to make sure that you have that stuff handled properly as it's coming through? Right? So chances are, if you have, I say chances are, this is probably wrong, but you know, the first, the first solution that they had here on the databases was, okay, you just create separate databases.

Let's say that you have 10,000 tenants just, just for kicks in whatever application you're doing. Are you going to run 10,000 different data process streams? I mean, that gets really expensive and really hard to maintain over time, like super hard to maintain. Well, yeah,

the, the, this was super, super, super specific to databases because it, you know, the question was how to ensure data isolation. And I was thinking,

well, what about like in memory state? Like, what are we talking about there to, you know, where's, where's the recommendations for that sort of thing? Yeah, and that's why it was interesting because when I asked the question, I read the question off to you guys.

It said nothing about databases. It was just, hey, application code, how should you do this? And it went very hard at the databases. Well, again, if you're moving data into storage, whether it's a database or a search engine or whatever, you know, you're going to have to be concerned about making sure you don't cross that data there. And again, it's unrealistic to think that you're going to add a new separate data stream every time a new tenant gets added because the maintaining of that is insane, right? Like we even mentioned, okay, you have a thousand databases. You need to upgrade them all because they're deprecating that version of the database. Okay. That's fun. Same thing happens with any software you're running, right? Like, Oh,

this library, this logging library is no longer it's there's a vulnerability in it. Okay. You need to upgrade your software. All right. Here goes 10,000 pipelines. But that is, that is the one true pro that i don't think we covered related to separate databases is that you can you can test like a database upgrade from like postgres 12 to postgres 13 on a smaller set of tenants right did that work out well and you could you know that can go same can be true of the schema related to those upgrades.

So if that's something important to you, you do have that ability. Yeah. I think it's easy to forget about the maintenance stuff that comes along for the ride with a lot of this. Because, I mean, Jay-Z's nodding his head over there the three of us for sure know that that when there is some sort of upgrade that has to happen like it can be incredibly painful especially when you have lots of different storage tiers in play right they all have the requirements they all have things that need to be just so. And you've got to get them perfect. They have to be perfect.

Yeah, we started this discussion, though, around, like you mentioned, writing async code in Java, and you mentioned coroutines. But for the C Sharp, though, I don't think you said the threading as tasks though. Right. And I didn't mention it as tasks. I said the async stuff. Yeah. Yeah. Okay. The async stuff's how do you worded it? But I was kind of thinking about this, like agree or disagree. And it's probably gonna be disagree, but the coroutine thing that Kotlin has, that feature that Kotlin has,

I was almost thinking, I wonder if you could make an analogy of that towards the parallel.forEach in C-sharp or in the.net framework, right? And center just system threading tasks. Sort of. So sort of a not. So co-routines can get incredibly complicated as you start diving into how the

scopes work and all kinds of things. If I remember right now, it's been, it's been a few years since I've done the parallel dot for each type thing. I want to say that it actually uses the underlying threads on the system, right? So when you do a parallel for each, it's actually going to the system threads and, and handling and managing those for you, right? That's a little bit different than the way

coroutines work in Kotlin. So I kind of think of it almost as like what, actually, I won't even do the analogy because I can't think of what they're called now, but the coroutines actually run in Kotlin zone management on top of threads. So they are way more lightweight than what a regular thread is. Like they even have examples. If you go into their documentation to where you run stuff and they'll have something that does a hundred thousand iterations and it'll finish in milliseconds, right? If you did the same operation with actual threads, you're talking seconds because of all the, you know, grabbing it, releasing it, grabbing it, releasing it. Like it just can't do it that fast. So these are sort of, they have a pool of threads that they manage behind the scenes and then they run their async

stuff on top of those. Yeah. But in C sharp, there was the thread pool that did the same thing. Right. But they're actual real threads though. right. Like they're system threads. I can't remember. It's been so long. Um, but that's actually one of the selling points that Kotlin says about their own, their own co routines is they are so lightweight that they're incredibly fast to manage and handle. So I will say, once you learn some of the nuances of it, it's not so black magic, but there are some weird intricacies to it that can really bite you. Like, for example, I mean, I won't go too deep into it, but if you have a root level scope where you're launching a co-routine, you would think that you could just put all the code inside it, inside a try catch. And if anything breaks, then you're good, right? That seems legit. You know, you do your launch and then you have your try and you do something inside it inside a try catch. And if anything breaks, then you're good, right? That, that seems legit. You know, you, you do your launch and then you have your try and you do something inside it.

Well, if something throws inside there, it'll actually leak out to the main thread outside of the context that you were doing it in. And in order to catch that, you actually have to create what's called a co-routine handler and pass that into your launch in order for it to say, Hey, don't let this thing leak outside my scope, right? Like stop it here. So there's weird things like that, that if you're not aware of, your application will crash, even though you thought you were trying catching something and you just didn't get it. It's almost, it's similar to what Jay-Z and I found out the hard way a while back about there being throwables or errors versus exceptions in

java right like if if you're only catching for exceptions then that time that that error comes you're hosed so yeah just weird things like that i think the point is we're just so spoiled by the ability to like spin off threads to do work compared to, you know, 25 years ago. Oh, for sure. Yeah. I like being spoiled though. Yeah, it's fine. For sure.

Yeah. I'll take spoiled, but, but I don't remember if I said it earlier or not, the biggest thing you need to worry about. Oh, I did. I think I did say it. If you're doing any kind of parallel programming, uh, you know, parallel in terms of C sharp or co routines and Kotlin or threads and Java or threads and Python, anything that sharing state that is outside of that thread that you're reaching into and trying to change, that is where you're going to cause yourself a problem. If you don't

know what you're doing with it, right? Because there's all kinds of race conditions that happen there. So if you ever find yourself going into multi-threaded land, be hyper aware of data structures that are thread safe, as well as ways to lock non-thread safe data structures, right? It's all about the data structure access. So just be really careful about that. Well, remember too, like a single lock isn't always good enough oh man the double lock thing that we talked about

a long long time ago yeah oh my god that's been a minute dude really yeah i don't even remember what it was for it's kind of standard standard nowadays yeah i would hope that co-routines are like handling it for you maybe do it i don't know don't do it yeah just like have something do it for me that's awesome let's see we talked about double checked locking in what episode is this seven this is 10 years ago was it was it episode seven because i'm not seeing the numbers no it was episode 11 ah close holy smokes dude yeah that was double checked locking what did we say about double check locking then let me see double i remember that there were some situations where things could slide through without the double the double locking which is ridiculous

um yeah our notes weren't as good then i just know that we talked about it but uh there wasn't like a whole lot of it's funny if you'd asked me 10 years ago you know uh i'm gonna blame who wrote this one I just know that we talked about it, but there wasn't like a whole lot of. If you'd asked me 10 years ago. You know, I'm going to blame who wrote this one. Oh, Jay-Z. Yeah. Oh, yeah, there you go. If you'd asked me 10 years ago, I could have told you all about it.

But yeah, I just haven't had to think at that kind of level in a long time. Our brains are FIFO cues. Yeah. All right. What's that? It was the first thing to go uh all right so so outlaw you want to introduce us to this next section here uh oh the oh because you so now you want me to like ask for reviews because you tricked me up here because like you deleted a bunch of stuff so that's why i was like yeah i looked at the time we've already been doing this for an hour and 10 minutes like

you know you know what we'll go on for another hour and 10 minutes we got this we got this we can really do this but it starts with uh you leaving us a review so if you haven't already done so we would greatly appreciate you leaving us a review uh it puts a smile on our face when we read it and we're really not that greedy we just ask for one star or more you know like whatever you feel like given you know right can you do zero stars does that thing i think you have to submit at least one i think somewhere yeah yeah i think i think so maybe if you mess with the query string yeah if you're trying to do the one just go ahead and click the zero and let's move.

Let's go forward. Yeah. So, you know, yeah. Thank you. All right. Do you want to play some games? Yeah. We head into my favorite portion of this show.

It's, hey, Joe, don't tell me how to do my job. That got violent quick. Yeah, well. Well, R.I.P. R.I.P. Boiled Water. You will be missed. Oh, nice. I like it.

You're welcome. You're welcome. You're welcome. All right. So let's play some mental blocks. This is episode 241. So according to Techco's trademark rules of engagement, Alan, you are first and you have a serious losing streak

that I don't mean to remind you of. I don't think you've won an episode since 1984. Yeah. I went negative last time. You won last time. I went negative, right? Did I? How'd you go negative? You can't go negative. I went negative last time. What did you say, Jules? I went negative, right? Did I? How'd you go negative?

You can't go negative. I don't know. No. I don't remember. Okay, hold on now. I think we tied at zero is what it was. So it doesn't even matter. I mean, I'm still on a losing streak.

It's nice for you to try and make me feel better about it, but it's pretty bad. Is that accurate? Let's go back to... i got him right yeah it was negative it was zero no no that was that was your bet your wager yeah your wages wiped out your points yeah no he said nope i mean you know that's how it works. Look, I'm telling you, I've watched Jeopardy a million times. You can go negative on Final Jeopardy.

And if you think I'm wrong, let me know in the comments. But your wager was 10 and you had 10 and you were wrong. So you just zeroed out your score. So let me know in the comments. But you still can't wager more than you got. Let me know in the comments. But you still can't wager more than you got. Let me know in the comments. I'm trying to get a new pair of shoes. You know what I'm saying?

Trying to make some dollars over here. You want some clicks? You got to say something wrong. You got to say wrong things. So Jay-Z. I'm not going to give away his secrets but sorry give us give us some categories we agree that right yes we zeroed out all right okay so uh categories are numerical place names Can I get an A? Quote, men. All of these responses will be men who have the initials AA.

Countries that start with the letter I. Dating apps. I'm going to go ahead and warn you right now. I don't think any of us are allowed to pick that category. If your wife ever hears it, you get it right. Pass it over. Kitty lit. Dis, quote, discontinued.

All these responses begin with the letters D-I-S. Let's do that for five. All all right so dating apps for five all right uh you said discontinued for five let's do it yes setting cell in 1610, it's the ship Henry Hudson used to navigate what we now know as the Hudson Strait and Hudson Bay. What is the discoverer? Really? I don't know it wasn't the nina the pinta or the santa maria so i was out i don't know where do you want a chance to steal uh there jay-z it was it oh i know this one uh disco fever the thing is the thing is,

so, so that was a total. I'm going to assume on your part, Alan. Yeah. Yeah. You missed it by one letter. Discovery.

Come on, man. Dude. I was like, that's why I looked at you. I was like, come on, man,

you got this. Just come on. Think it through me. You should get half mad. You're right there. All right. So I'm going to put a little asterisk next to that one. I've mumbled is what happened.

Yeah, sure. Okay. Sure. That's what, that's what we'll say yeah um all right joe here you go all right got it it's a date amigo or wow number one hits all of these will concern songs with the word one in their title. Oh, my. I could do that. This 1990s metal hit. Okay. So, non-musical theater, New York Times obituaries, J, in quote, J law,

where all responses begin with the letter J or animal idiom brain teasers. I'll give you the meaning of an animal idiom and its initials. You give me the idiom. That sounds fun, but, uh, um, I mean, yeah, let's, let's try animal idiom initials

four brain teasers i said yeah it's gonna go terribly i'm so tired right now let's just do it okay it'll be fine you can you can do anything you wish or go anywhere you want in this life. And then the initials are T W I Y O. You can go anywhere. You can do anything you wish or go anywhere you want in this life. T W I T O. T W I Y O. Y O. T-W-I-T-O? T-W-I-Y-O. Y-O. You can do anything you wish or go anywhere you want in this life.

No? The world is your oyster. That is correct. That's ridiculous. That's ridiculous. That's how it's done, Alan. That's just... I'm asking Claude. You notice how he didn't say the world is your

oist? Or oistry? Oh, dang. Okay. Here you go, Alan. time to redeem yourself cyber security female firsts fairy tale adaptations opposites in novel titles we've replaced one or more words in a book title with their opposites. You have to give us the correct original title. Okay.

On the periodic table. And lastly, there's an app in quotes. There's an app for that. The letters APP will appear somewhere in each response. I like the title thing. Opposites of novel titles? Yeah, let's do that one. This should go well.

Okay, and you're... Oh, five. Oh, yeah. Okay. I have confidence in you. Me too, yeah. Supreme confidence. No, I'm being serious. Oh, okay. jane austin's shame and impartiality shame and partiality do you want to phone a friend is that your final answer

uh i'm sorry but the correct answer was pride and prejudice Do you want to phone a friend? Is that your final answer? I'm sorry, Alan, but the correct answer was Pride and Prejudice. Oh, come on. I thought for sure. Shaman Part Kelly was the sequel, actually. Well, I mean, it came out after. Okay. Okay. Okay. Here we go. Well, Joe, you get your choice of any of the categories we've gone over so far. So I'm going to quickly say them again.

Numerical place names. Can I get an A in quotes men countries that start with the letter I quotes dating apps. That one's off limits for you. Kitty lit dis quote discontinued. It's a date amigo. Number one hits non-musical theater, New York times obituaries, quote, J. Law, animal idiom brain teasers. I hope the listeners appreciate when I do air quotes. Cybersecurity, female first, female, no, I said female first, fairy tale adaptations, opposites of novel titles on the periodic table. There is an, quote, app for that. And so help me if you already knew the topic that you wanted before I read all of those again,

I will come through this microphone. I do write all of them down. So, yes, I thought you were doing it for the audience. Sorry. I think cybersecurity would be interesting, but I can't resist fairy tale adaptations. Okay. Four. Oh, always adaptations. Okay. Four. Oh, always five.

Okay. Just double checking. Yeah. Always. Let's do it. Pedal to the metal. In Sarah, in Sarah pin bros poison. This fairytale group suffers from work related lung damage and missing limbs.

What? Fairytale adaptation poison. Because there's always the chance that I mispronounced the name because you might have heard that about me by now. I'm just going to put here in our chat, that's the name. I think I... Pembroke's. Very helpful. Is that what I said? just going to put here in our chat that's the name i think i am burrows very helpful yeah very helpful is that what i said he's got it now sarah pembro's yeah yeah no what i said did i did i mispronounce it i think it's pretty close yeah yeah i need to get the answer though obviously

yeah in sarah pembro's poison this fairy tale group suffers from work-related lung damage and missing limbs it's the seven dwarves that is correct took me a while to figure out what the question was so this is a fairy tale adaptation so it's about snow white but poison you know like who like miners you know dwarves golly man i do whatever i wager it all outlaw all his points all zero of your points against all of his yes i don't even know why we're doing the final round but here we go television history is the category and um you can send me a private message with what your wager is and your answer uh i know your wager alan according according to the bbc this 1953 event did more than any other to make television a mainstream medium.

1953? Yes, that's the correct one. Not 1853, but 1953. According to the BBC, this 1953 event did more than any other event to make television a mainstream medium. Oh my gosh. No, that's not it.

I take that back. That was too early. Let's see. What did you say? Okay. Got your answer. No. And I've got his wager,

but I don't have his. Yeah, I'm still thinking. What year was the O.J. Simpson trial? I'm pretty sure it was 1953. Yeah, that sounds about right. Did they have Super Bowls back then? I i mean clearly they're on like episode you know 40 of it now so yeah i mean math let me do some quick math yeah definitely wow i don't know all right so did i stump both of you then i i just don't know i can't think all right so let's see alan wagers zero plus or minus

not sure how that works but okay and you deleted it but you did say the, the moon landing, which is wrong. That was 60s. Yeah. I was way off. I just couldn't think of it. And then, okay.

So then Joe said his, his was 10. He wagered 10 and let me go ahead and get right here. And he said, man on the moon. And I am sorry, but REM did not come out with that song just yet nor was the movie made about it um yeah i knew so that is that is wrong not so we both went for like basically space stuff that's funny yeah and i knew that that was too early because it didn't happen till like my parents were a little bit older the correct answer is the coronation of queen elizabeth the second like who would have who

would have yeah wow all right well i tied again it was it was the first thing that came to my mind yeah yeah clearly man see this is how you end i mean i think you know there is an asterisk on this episode on this you know particular episodes game show mean, I think, you know, there is an asterisk on this episode, on this, you know, particular episodes game show. So I think that, uh, you know, I mean in the, in the history books, it's going to be like, did Alan, did Alan win it? You know, maybe. No, no, no.

I thought. Question. Like maybe he broke his losing streak. Uh, not really. You know, I went, I went zero more. So definitely in negatives. Hey, I got an idea for next time. Instead of doing like a four where you pick from any category,

what we could do is the person who gets the two questions, the other person could pick the category. Ooh, four of them. I like it. Yeah. I'll get to pick a lot. So the person who gets two questions gets to pick the category for the other person? Yeah.

Wouldn't that give them that much more advantage? The person who answers one question. Yeah. Wait, what? One person gets two questions, and the second question will be, the category will be picked by the other person. Right. So if in this case I had two questions that were asked of me, he only had one,

I could pick the one that he has to do for his second. Yeah, just consider it. I don't know if it's a good idea. You get to pick the one that he does for his second. That gives you the advantage, Alan. That's what I'm saying. So what I'm saying is the person who gets two questions has a disadvantage on the second question.

Oh. But then how would that work a disadvantage on the second question oh but then how would that work for you on your second question we'll we'll flesh this out before the next one yeah we'll flesh and we gotta do it live if i'm saying no we do only three questions three questions and final only oh only the three oh that makes more sense okay i, I like that. Wow, that really gives the advantage to the person who goes second, though. Because then they can pick what they think is going to be the hardest category. Yeah, well, then it's almost like

even ground. Yeah, I'm saying the person who gets one question should get to pick the person who gets two questions category in the second question. Yeah, the second one. I like it. If you're going second, you get the advantage

because you're going to pick the hardest question for him. Yeah, but you still get two questions as the first person. Yeah. I like it. I clearly excel at this game, so this could only help. Okay. Well, if there's anything I've learned is that I knew I shouldn't have uh i shouldn't steal a

mixer from work but it was a whisk i was willing to take nice nice so i was trying to figure it out you're good that was good uh hey i got a weird one for you so elastic search is going open source again uh so uh if you remember a while back, Elasticsearch started out as just being open source and it kind of moved into open core. And then there was some issues around cloud licensing and stuff that happened several many years ago now with specifically with like Mongo and Elastic and a couple other owners of open source projects that kind of felt like they were getting a raw deal from some of the cloud providers, mostly AWS, for offering their services and selling them. And so they changed licenses.

And that was a big debacle because then people didn't consider them open source anymore because, you know, the various limitations being placed on the use of that software. And so that was a whole big thing. Well, Elastic has gone and gone open source again. They've changed their license. And this is just like hot off the press just a few hours ago. So I haven't, you know, there may be some stuff that still kind of comes out about this. And the press release about it is kind of weird. It was written by the founder of the company, Shea Bannon.

And it's broken up into weird sections, listed in brackets that I guess are Kendrick Lamar songs. I'm not kidding. So it definitely is a weird read. And I only know that because someone told me. I was wondering what all those were. Weird Read. And I only know that because someone told me. So it's weird. I was wondering what all those were. And the new license now is AGPL, which is an open source library.

I don't think anyone would argue that. It is an OSI approved license. So that's kind of the closest thing we have to a standards committee for open source licensing. So it's an open source license, so you know it's a it's a it's an open source license but it is not a permissive license it is a copyleft kind of aggressive license that you know a lot of organizations kind of avoid um shipping because of so uh i'm interested to see how this kind of plays out over time because like yeah it's open yay but also it's really restrictive so kind of scary but it sounds like they may be keeping some other

licensing options around so i assume if you you know sign up for their gold you know tier platinum whatever partner uh kind of service they have then that's where those kind of multiple licenses uh come into play so you can kind of license your software differently uh so i'm really interested to see you know how like your guys take on this but also just how this kind of plays out over the next couple weeks i can tell you that after hours trading on elastic search stock symbol is not loving this interesting interesting um so i don't it said it's agpl right yeah agpl so i went to our trusty friend tldr legal that outlaw turned us on to probably 10 years ago also and the it shows agPL V3. I'm going to assume that's probably what they're going to. And the short list here is they have three categories, right? You can, you cannot, and you must when it comes to it.

So you can use it for commercial use. You can modify it. You can distribute it. You can place a warranty on it. You cannot sub-license it, meaning I don't think you can sell it warranty on it you cannot sub-license it meaning i don't think you can sell it i think you can't lease it to somebody else yeah there's stuff with it you can't put your name on it and distribute it okay you can't you can't grant your your license to somebody else i think it's what it means like you can't hold liable because you can expand either one of these

things so sub-license says describes the ability for you to grant or extend a license to the software. Yeah, that seems weird. You have to include the copyright. You have to include the license. You have to state any changes you made to it. You have to disclose source. Describe whether you must disclose your source code when you distribute the software. This has always been the gray area that I think kills a lot of the GPL type stuff because I think the gray area has been,

does that mean you have to disclose your source for your entire application or just for the things that you made changes to on Elasticsearch, right? Well, they also, in the paragraph above, they say, since websites and services are never distributed in the traditional sense the agpl is the gpl of the web yeah and they mentioned some other they say grafana is also agpl which i looked and it is i didn't i didn't know that so maybe it's not as scary as I thought. Maybe people will just love it. I don't know. Developers, we'll see. Well, here, hold on.

It says, but the additional clause, which makes it so that source code must be distributed along with web publication. It sounds like you got to open source your application. This is, again're this is again, this is why anytime you start getting into the GPL realm with any software you plan on using, you really need to speak to your legal department or somebody that talks to

your legal department to find out if it's usable. I, us not being lawyers, we don't know exactly what this means, but that's always been the gray area with GPL licenses, which is why a lot of places just try to avoid them. Um, so this is, this is interesting and curious, but like Jay-Z said, they said in that article that they are keeping around their other two licensing things that they have uh elv2 and sspl which i don't know what those are either so uh server side pl that's the one that um mongo i don't know if they use the same one but it's kind of similar as basically like you if you're selling it to

other people you're kind of they count it as like redistributing um okay yeah that's interesting it's an interesting move that's a hard move as an organization to make you know it's going to confuse customers it's going to confuse developers it's going to take a while for the dust to settle i mean if i remember right wasn't one of the reasons why they kind of backed off of the open source was because companies like Amazon specifically and, and cloud providers were wrapping services around their software. Right. And then selling that. So,

so basically like Amazon would go up there. AWS would create their own search, um, managed software. And it was really just running elastic search behind the scenes with some of their own goodies on top of it. And an elastic search rightfully. So it was like, wait a second, like, why should you make money off this when we've built the entire software platform and you're going to go take it for free

and turn around and charge people to use it on, on your, you know, compute engine. So it's a tough one, right? Like it's this, this kind of thing is really hard. I venture to say all three of us think of Elasticsearch is an amazing product. It really is. And they're kind of in a hard spot when it comes to this. They either need to sell services through their own platform or they need to somehow be, they want to ensure that if you're going to benefit from their open source efforts, that everybody else can benefit from what you created in your application, I think is what it boils down to. Yeah, but I mean, to JC's point about after hours, it's like almost a 25% drop in the stock's value after hours. Not bad. drop in the stock's value after hours. Not bad.

Yeah, I mean, may bounce back up tomorrow. It's an interesting move. I don't even think I knew that they were. I didn't know. When he traded. When Jay-Z said that, I thought he was joking, and I went and looked, and I'm like, is that true? Is it really?

But yeah, they are publicly traded on their stock symbols. E S T C. And yeah, 2018. Holy smokes, dude. They, they took a beating. Wait, but this is their guidance. Earnings call transcript.

Right. So maybe it had nothing to do with this open source thing it sounds like their earnings just weren't what they wanted it to be yeah that's fair there are comments in here about like the stock drops after the q1 results and q2 revenue guidance below the estimates i mean in fairness like i don't ever understand any of these things that drop like nvidia right they did their their earnings last night and they have killed it. Absolutely killed it. And then they went down today and I'm like,

yeah, didn't kill it enough. Yeah. They didn't kill it enough. They beat, they beat projections and beat even what anybody thought they were going to get to, but they didn't reach the highest echelon of what people were expecting.

And so they dropped a few percent. It's like over 6%. Really? Yeah. They, they dropped over 6% today. It, it makes zero sense to me.

Like I've never understood it. I, whatever. And that is stock investing. One Oh one. And yeah, absolutely insane. So what we're going to do is we we're gonna throw your money into this thing

and we'll just see what happens so we'll go for the ride it's gonna be a wild ride it's basically like the stock market is basically like you know just giving your money to like a meth head like you know you're just you're just in for the treat you're gonna see what happens see where we go so you being a super big apple fanboy have you ever paid attention what happens with theirs? They'll announce some big thing and they've done great. And then the next day they're down 10%. You're like, what?

What happened? Yeah, yeah. So I hate how you classified that as me being a fanboy and that's why I might pay attention to their stock. Coincidentally, I am also a fan of their products and coincidentally i also do pay attention to their stock i do watch that one and yeah it is kind of funny though like it's weird to me how you you know a company can like say like we we think we're gonna this is this is what we expect to the target we expect to make

next quarter or you know whatever their cycle is right usually quarter and and then they beat that and the market's like you could have done better it'd be like punishing your kid for coming out it's like i got an a but you better get an a in that class they come home with like 98 you're like dude you didn't get 100 you're grounded like that's that's what it reminds me of like what do you mean you didn't do the bonus points and get 110 right yeah yeah the whole thing is good because like you can imagine me like okay there's this company i know elastic i think they're a great company and they have a great product so i think they're going places in the future so i'm willing to pay more for their stock and someone else is like oh well I see that a lot of people think this company is really good and that they're going

places and stuff. I think that maybe they're just a little too overly optimistic. So even if I agree with them, I don't think they're valuing it correctly. So I'm going to value it lower. And so there's this weird push and pull over like people's predictions in a way so that it's like the the price itself never actually reflects like what it is today it's more about what people think it's going to do in the future and so it's just so weird i don't get it i mean elastic search as it specific to them though and and i i can just generically lump them in with like a bunch of technologies that that are similar to them like i don't understand how they made money to begin with

right because like you know because they're open source you you could buy a license if you wanted support or if you wanted like x-pack features in the case of elastic right which if you never looked at the x-pack features that they had you know they had some like cool machine learning things that could do could be done like on the fly against your indices you know there there's some cool capabilities there right but if you didn't need any of that guess what you can do you can just download elastic search and like you know run it in your own cluster and as long as you're willing to like maintain it yourself guess what good you're good you got it that's it you're

you're all set and so i say i could lump them in with other technologies because you know uh look at look at like a kafka for example like Like, huh, like Confluent does make money, I guess, doing something. But I guess Kafka is maybe a bad example because technically it's under the Apache project, right? Kafka is Apache. Yeah, yeah, yeah. It's not GPL. But Linux, Linux is GPL.

But Confluent definitely makes their money selling services around Kafka, whether it's consulting or their managed products. Well, and you bring up Linux. For decades now, I've never understood, how is Red Hat still around? But people pay for a free operating system that you can go and download the source and you can maintain and you can do whatever. But yet people pay for a free operating system that you can go and download the source and you can maintain and you could do whatever, but yet people pay. And it's in, yeah, like Jay-Z just said, support is what you're, what you're paying for there. Yep.

But I'm just so surprised that that, that there's that level that many that are paying for the support that are like able to fund it because it really there's this other new model and i forget what it's called where the the the companies are they'll they'll fund like these open source projects. Where are they called? Is that what it's called? I don't think...

That sounds wrong. That sounds like something you got from the Silicon Valley. How about funding the foundations like the cloud-native? Yeah, yeah, yeah. Where multiple companies will fund a given project and like you know you could have your own uh open source project and you could be paid to work on that project and and these companies are like yeah we think that that one's valuable and we're going to fund it you know like that kind of model to me makes more sense because then there's like

the the customer is a little bit more clear you know about it i don't know yeah it's bizarre it's like my sequel when they were when they went from freebie to to doing the the service or the the paid stuff yeah there's tons of them out there postgres like how's that still around like why oh so many of these technologies that, like, we rely on, like, they're big. But it's cool that you just download it for free. But, yeah, somebody's got to make money somewhere with it, right? So, well, I guess maybe I'm showing my age because, like, you know, it used to be that you would you would buy the software from microsoft

so you were paying for the license for it and you were getting this paying for the support for it or you could just pay for the license and go about your way if you wanted to and now the world has shifted into like we'll give you the software yeah sure take it but if you want our help supporting it then you got to pay us for that you know even kubernetes is like that right like you know from google like you could you go and download your own yeah you know download kubernetes run your own cluster if you wanted to you know you're free to do it you'll be throwing money at them soon though because that's that's nightmare that's basically what it boils down to right at some point everybody has like this

breaking point where they're like that's it here's my checkbook right at some point everybody has like this breaking point where they're like that's it here's my checkbook you just go ahead and take what you need out of it well a lot of times too it feels like i don't know if you've noticed this if this has been your experience where there's like this risk kind of thing to where your boss might say like we'll have no problem in certain software about like, yeah, I know we'll, we'll download that open source version. We'll use that blah, blah, blah, blah, blah. And then like, you'll bring up some other technology and you'd be like, I think we need support for that one. I know.

I know. I actually know people that like several people that don't like open source software. Like they want to pay for a license because they feel like that support is going to be better. And I mean, there's, there's a, there's a little thing that rhymes with,

um, EXT that we've done in the past that I felt like their support, like wasn't worth it. Right. Okay. We paid for a license, but you know, we just paid for it because we're going to have figured all out on our own.

And yeah, I don't know. It's weird. There are people that are of the mindset that you don't get quality unless you pay for it. And're going to have figured all out on our own. And yeah, I don't know. It's weird. There are people that are of the mindset that you don't get quality unless you pay for it. And it's like, yeah, I don't,

I don't believe that either. Well, I guess the thing that I was thinking of that wasn't even about the quality of it, it was just like, it's kind of odd how certain technologies, you know, like the powers that be will be like,

Oh, those are fine. Like they're kind of trusted true like you you don't need to pay for support for that but then other technologies they'll be more guarded about and they'll think like no we need to pay for that license so so i mean going back to your original question like what do i think about this for elastic search like i don't know i mean you were making money before i guess i i'm i hope it works out yeah i mean it probably will work out like you know who are we kidding they're probably recognizing like hey we can just you know we're only selling support anyways.

Or like custom features like XPAC. So many open source projects like that are actually large are really, you know, run by a company. Like there's like one very clear steward of that, you know, source code. And while the source code itself is open source and even anyone can theoretically take it and run with it, there's like one clear community you know that's built up and it would take a lot of energy to really split that community at all into you know some sort of fork around it and so it's uh it's this weird kind of split where like open source can mean like the little project you did on the weekend and threw up there

it could also mean kubernetes which is run by a foundation funded by google microsoft and amazon and all these other companies that like hope that you go host with them because it's easier right i mean as long as they as long as and i will have to trust their lawyers with this this license this a gpl license because i'm i'm no lawyer i don't know if you've noticed but but as long as this protects them from the point of view to where like going back to what Alan said at the beginning, right? Like, like, cause the whole risk that why they went this route was because of companies like Amazon that were like spinning up services around their product for free

and then charging a boatload for that thing. And they weren't getting any part of that, that pie. Right. So maybe this license protects them from that, or maybe they don't care about that anymore. And, you know,

so they're like, eh, whatever. Yeah. It's hard to say. Well, with that, it's now time for my favorite part of the show is the tip of the week all right uh

so uh have you ever worked on a problem where you need to get some sort of fix out but you can't reproduce the fix and you got to kind of you can't reproduce the problem and so you got to kind of take a guess as to what the solution is maybe you're adding some logging or you're you're adding something you think i think this might be the the fix, but I'm not sure. Uh, I call that a speculative fix. And so, uh, wanted to think like if you're in a situation like that and you're not sure if your fix is going to work, uh, just got a couple of little tips here. Uh, one is just to over communicate. A lot of people know, like mentioned it like three different times that you, uh, that you are not sure that it's going to fix it. Cause like a fix goes out in a while or something happens, a crossover in the next

week or whatever, sometimes people will end up feeling like your fix is going to relieve some sort of pain. And if it's a maybe, then they can feel really let down if it doesn't and that can stink. And so just make sure you mention it over and over and over again. Sometimes over-communicating is a good thing and it protects everybody. You know, it's those proper expectations and it's just a good thing. Also, I want to know who hurt you, JC. Who didn't hurt me?

One other tip. So this came in handy for me is uh just keeping screenshots uh and good logs about what you have to do in order to fix it um not only is it you know just kind of good to document your stuff and sometimes it comes in handy but also uh sometimes just having a screenshot something able to kind of look back and say like i you know i thought i tested this but it's been such a confusing thing and i wasn't really sure and i had to take some guesses let me go back and look and like oh there's a screenshot that shows exactly what I did and it does show that I tried this or I tried it in another way that I thought and so now

uh you know I I'm not confused about that so that's a good thing so you should keep screenshots save them forever throw them in obsidian and I do have another one uh so shapes two and that's shapes with a z it's a video game very similar to factorio it's about automation you're going to be placing uh belts what's cool about is you're actually um taking shapes like a square and a circle and then you're using them to construct more complicated shapes so you might take that square circle cut it up into quarters rotate it um stack them on top of each other paint them red green white and whatever and basically end up making a pattern and you kind of shove it in this black hole at the end and um what the result is is very similar to factorio

except that uh it's got just enough of a twist on the formula like you don't have to go out and deal with like kind of finding copper mines and you don't have to go out basically finding resources in order to kind of make your stuff that's all supplied to you and uh you also don't keep building a bigger and bigger and bigger base you're basically making however many of the complex shapes you need and you can kind of tear your factory down over and over and over again. And the result is basically a puzzle game where you're just kind of like making these cool little factories to kind of make the shape that you want in a way that's somewhat efficient so you're not waiting 10 minutes

for the number of items you need to be made. And then when you're done, you can tear it all down and move on to the next set of sets of shapes. So it's got like a big emphasis on kind of solving that puzzle over and over again. I just thought it was really cool. So if that sounds like something cool, if you feel like refactoring and automating and dealing with kind of abstract puzzles, then I should give it a go. And if you thought he was describing Tetris with some of his descriptions, it is

not. It's not that far off. It's pretty far off Tetris. But it's on Steam and it is overwhelmingly positive on the reviews. That's very cool. And I did play the first one and I didn't recommend it, but the second one I definitely do.

Cool. Cool. Excellent. All right. So mine, I, there were a couple of things that I ran into that were pretty interesting this past week. So one is, I know there's been times everybody's done this.

You're debugging some code and there's some things that are taking too long or you're trying to figure out how long they're taking. And so inevitably what you'll do is create some sort of either a starting time when something happened, and then you'll sort of do take a second time and do a diff between the times to figure out how much time elapsed between them, which is perfectly fine, but it's definitely a lot of lines of code just for doing something simple. Well, in Kotlin, there is actually a method called measure time millis that allows you to just wrap whatever you want to measure how long it took. You just wrap it inside a couple of curly braces and you're done. At the end of it, you have the exact amount of milliseconds it took for that

thing to operate. And it's really sweet and useful. So, uh, have a link to the documentation on it. It even has an example there. That's really awesome. And then, uh, recently I was doing some Google cloud training. It's actually called cloud skills, boost dot Google. And what was interesting? I don't know if you guys saw this. I know outlaw, you did some of the training after, after you do the labs, you actually earn points, right? And I'd say by and large, I'm usually not a sucker for that kind of stuff, but I saw it and I was like in seventh place and I was kind of irritated about it because I was like, man, I got all the points I could get. How's anybody beating me? So you had the same thought, yeah? Yes. Yes. So, so I got annoyed by that because, you know, if I could be number one up there, I want to be number one. But what I found is if you start going

into this, you can do other trainings and other things and get points. But in order to do that, you have to pay credits and to get credits, you either have to trade dollars for credits or whatever to be able to take some of these other courses. Well, that led me down this path of, okay, well, what's it going to cost? Because I'll drop in, I'll drop in 20 spot here so I could beat some people. Right. And I seriously thought about it, but I ended up on the cloud skills, boost.google slash payment slash new page. And what's interesting, and this might be worth it for anybody considering something like this is you can get an annual subscription to Google skills or whatever it is. And it's basically you get $500 in Google cloud

credits. All right. Which means you could take a whole bunch of things. And you get a certification voucher up to a $200 value. So you pay $299 and they're going to throw you $200 to be able to go get certified in something if you want. You also get a $500 additional Google Cloud credits per year after passing a certification exam. So now you're at a thousand dollars worth of Google credits for that $300 price, assuming you take and pass one of their little certification exams. So, and then you also get included on calls and trainings and other things, and you get one-on-one consultation with Google cloud experts. So this could actually end up being something that pays major dividends for you. If you want to get credentialed in Google cloud, like let's say that you wanted to get certified

as an architect in Google cloud, and you want to pay for an annual subscription, this could potentially pay back major dividends. Now there's also a cheaper version to where you could pay monthly $29 a month. And what this does is it unlocks 700 labs and authored courses that you have access to. And you also get curated learning filter by role skill topic and save your programs. That's all included in the two 99 as well. But if you don't want to pony up, you know, $300 upfront, $29 a month is not bad for getting access to the kind of stuff that could actually take your skills to another level in Google cloud. So, um, I thought I'd share that. I thought it was pretty cool. Um, almost did it because I really didn't like being in seventh place. So, you know,

yeah, I got that same thing and I was like how how is it like i couldn't have possibly done anything different i got every point that was at my disposal to get how am i not at number one yeah and i was so like the the the number one score four thousand something right multiple times like i could even if i did because the labs in the course that i took you were allowed to take them three times and and it didn't matter you uh any one of the the times that you took as long as you passed it one time that's all that mattered but theoretically you could take it each lab three times and pass three times right what would i still wouldn't have had enough yeah well i don't know if i would have right but my point is is that

even if i had the the other point the higher the highest score was like instead of three times my score it was like more than six times my score so So I'm like, there's no way I could have, I could have gotten it. I had the same problem. I looked at the guy that was in or gal who's in top on ours and they were more than 10 times what my score was. And I was like, hold on a second. And that's when I started doing the research and I was like, Oh, I see, I see what's going on here. Yeah. The, they say that that that innovator is plus the one that for 299 they say it's over 1500 and developer benefits for 300 for what they show that you get it totally looks like it so if you're somebody that would really hammer down on it it's probably worth it i did include a different

link though like an easier link um because i don't know why yours was payment slash new because you could just go to slash subscriptions yeah i don't know and it did the same thing so yeah i don't know if you like to type less then maybe go to you know slash subscriptions otherwise you know or you could just put the link from our show notes because we have amazing show notes up www.codingblocks.net slash episode 241 W. That's right. Yeah. So, so, all right.

Um, well, did you want to do this next one? No, no, I think, I think you found it. Oh,

did I? I think, I don't know. There seems to be some debate about that. So this was a, uh, tip. This was a tip that was actually given to us um oh shoot in our oh ivan kuchen uh gave us this tip in one of the comments on the episode so if you too would like to leave us comments and you know explain basically like why everything I said was wrong, you can go to codingbox.net slash episode 241

and you could correct me. But Ivan, we had talked about JQ and I think in that particular episode, if I recall, I had given YQ as a tip of the week, which is like the YAML equivalent to JQ, which if you're not familiar with JQ is a JSON query utility. Well, Ivan shared this one called Dazzle, which is comparable to both YQ and JQ. And Dazzle is short for data selector. But this one tool supports JSON, YAML, TOML, XML, CSV. So, you know, you only have to know the one tool to do it. So I'll have a link to the GitHub page that has instructions on how to

use it, how to install it. You know, this is something you can brew install. So, you know, no worry about downloading and compiling. This is 2024, so there's a way to brew install. And similar to Alan's tip of the week related to the Google training, like Alan said, we're both taking some Google training. And they shared, I don't know if they shared this in your talks, Alan, but, um, the there, we love our cheat sheets, right? So it's the Google cloud products in four words or less. And what it is is there's a developer cheat sheet and you can go click on it and it's interactive. So like you can say, um, you know, okay, let me see all the data

analytics stuff. And it's all in like a light blue and you can, you can hover over any one of the things. So you're like, Oh, big query. What is that? And it's data warehouse slash analytics, but I can click on data analytics and it'll like flip every tile. And instead, if I want to look for like, Hey, what would be a good uh tool for visual data wrangling and now i can see that answer i can hover back over it and it's going to say a really small print one data prep by terrifica you know some so my point being is like uh you can easily go and explore what the product offering is that Google Cloud has. And try to figure out, oh, what does that do?

Or where might I use that? Or what's the best tool for this type of problem? So yeah, it's pretty neat. That's very cool. That is. So we'll include a link for that in the show notes, as well as plenty of... This is actually a link-heavy show. I was looking through, because I've been adding in a bunch of links as well as plenty of this is actually a link heavy show there.

I was looking through cause I've been adding in a bunch of links as we've gone through for various like side topics and whatnot. So yeah. So check the show notes again, coding blocks.net slash episode two 41 and subscribe. You know, if you'd like this, otherwise, you know, I get it. Can't please all the people all the time, I guess. Hey, yeah.

Um, yeah, that's good. Hey, Hey, and we did, Oh no, we didn't.

We should have mentioned, check out our Slack, codingblocks.net slash Slack. And I guess that's probably good enough.