I just want to thank you. You've done an outstanding job with the instrument import.
Thanks. Thanks.
Oops. There we go. Good morning, Nick.
Morning. Hi, Nick.
Hey. Well, just to kick it off this morning, I just sort of want to spotlight some of the work Charles has done. So,
do you want to tell us about the import real quick, Charles? And then I can
pull it up on the screen.
Yeah, so it's this pandas code that reads in a text file from this
a text file from this Shimazu Nexera. And it just sort of cleans up the data and the column names and
puts it into a readable pandas or readable pandas data frame.
Exactly. So, Nick, so essentially at the laboratories, when
when the data comes off the instrument, it essentially just looks like this.
So, this is what the scientific instrument is spitting out whenever you send in the test result.
So, here it's just may look like a bunch of godly gook at first, but you'll see, you know, we've got
CBDV, CBDA, CBGA. So, this is what the instrument's actually measuring,
and we're getting a lot of readings, but primarily what we're looking for in all of this mess
is the concentration. So,
there's a lot of data, and we really just need one data point. Well, we need a couple data points, but
so this is where data wranglers like Charles play a critical role. And so
Charles has written
this import method. So, this import NXSERA, and so essentially,
you know, all you have to do is point to that data file.txt
and
we now have that data in the slightly cleaner format. So, we now have the compound, and so, for example,
if you look at the last observation,
well, it looks like there's a lot of columns, so let's iterate over this real quick. So,
did you want me to drop some of those columns? Well, a principle that the Craig Demkin, Dr. Craig
Demkin, he's an economics professor at UNC Charlotte, he stressed to me, never throw away data,
and it's not a good idea to throw away data. So, he's not going to be able to do that.
So, he's going to throw away data, and I mean, to a certain extent, you know, you need to clean up the data,
but it's a good principle to keep in mind, and his observation is, you know,
especially when you start to take means and things, you know, you start to, you know, you start to,
you know, lose some of the data, and you know, you don't want to just be throwing away variables and
portions of the data willy-nilly. So, you know, as data storage becomes cheaper and cheaper,
my philosophy is just archive everything, so just save it.
There are, here, so let's try to print out all these variables here, and then we can just talk
about the things that are interesting. So, I'm not 100% sure how we can iterate over
this one observation, but we can try a couple things. Okay.
So, I kind of want to print out this whole thing, but it's a little long. I think.
Okay, so now we can see, so this is essentially one observation. So, this is one compound of
of one analysis of one sample, and so we've got all of these data points for this one compound. So,
128 data points. So, that's probably excessive, and as you see, a lot of these are just blank,
but I'm going to try to get a little bit more of a sense of what's going on here. So,
the things that you do need for certain, you need to know the compound. It helps the analyst and
the software to know where the data is stored on the instrument. So, this is the actual file path
on the instrument. So, this is the actual data that's stored on the instrument. So,
this is the actual file path on the instrument. So, scientific instruments are essentially wired up
or wireless to the computer, and so the data is typically stored on that computer.
So, then you also want to know the sample name, the sample ID, depending on the instrument,
then the sample type, if the analyst has entered it, the retention time. So, just a brief,
brief, very brief, so just a brief
introduction to a chromatograph. So, essentially, you're running the analysis on an HPLC or
another scientific instrument that does chromatography, and
so your, say, runtime may be maybe on a faster machine, maybe, or a faster instrument, maybe
it could be as low as four to seven minutes, but maybe, you know, a typical would be 11 to 16 minutes
per analysis for a single sample. So, you're going to have to do a little bit of a run time
to get that done. So, essentially, you're going to be passing
little injections of the sample through the instrument, and
if something's detected through chromatography, you'll get a response, and then the area of the peak
represents the amount, sort of the concentration of a particular substance in that injection.
How do you know what type of substance it is? Well,
that is the retention time. So, here you're seeing the retention time of 6.323.
So, let's just conjecture that this is six minutes and 23 seconds.
This is THC, and then what's been done is people have isolated THCA, and through repeated scientific studies,
they've been able to detect the results of the test. So, you're going to have to do a little bit of a run time
to get that done. So, in these scientific studies, they've determined that given your parameters,
THCA should elude, so that's when it comes off your column and creates this peak, at around
you can calibrate your instrument to essentially label this peak automatically as THCA.
So, we've got that, and then the concentration, 49.445, is this area under the curve.
And so, that represents the concentration of THCA in the sample.
Oh, that was injected through the instrument. So, those are the main data points you're looking for.
Of course, the chemists may be interested in some of the other variables. So, for example,
they may be interested in when the peak started and when the peak ended, because you want a nice uniform peak.
You don't want lumpy peaks, so to speak.
And a chemist could probably tell you a lot more about more of these variables than I.
And so, that's why I just resort back to the philosophy of never throw away data.
And so, may as well save it in case someone needs it in the future.
So, let's just sort of a quick scientific analysis just to give Charles props for turning this data,
this text file into a reasonable data frame that we can now do work with.
So, for example, we can find a particular sample.
What was the variable's name again?
And so, with the click of a button, you now have all of the compounds for this method.
It looks like there could have been two runs of this.
So, let's actually just find out all of our samples real quick. So, this is the beauty.
So, we're just basically going to show what's so cool about the work Charles has done here.
So, because it's all of this data is in a data frame, we can make short work of it.
So, we can find the samples.
So, say you were looking for the sample name QC-PREP-A.
Well, now you have all of the cannabinoids that were analyzed.
And you could take it from there.
And so, essentially, this is a critical step in the data collection process because I'll just let you know,
when I started as a laboratory analyst, essentially, until there was a good way to import this data,
I was essentially just transcribing all of these concentrations by hand into the database.
So, as you could imagine, you know, as you can imagine here,
so for each of these, I would be transcribing the concentration.
So, as you can see, it's easily quite a nightmare because you're having to do all of this crazy parsing
and the number is just hidden right there.
And then for one sample, you're having to do 11, in this case, 11 compounds.
And so, you know, 11 times 3, I mean, that's 33 data points you have to enter for three samples.
Or you could use Charles import method and just import all the data.
It's ready to go. It's in the pandas data frame.
And my philosophy with Python is if you can do it with a computer and you've got enough time and willpower and know how,
then you can do it with Python.
So, long story short, awesome work, Charles. Just phenomenal.
Yeah, that's really cool.
And Charles has actually pushed this to the, like, CamLinux engine.
And so, Nick, this is sort of maybe something up your alley.
So, this is essentially an interface for cannabis analytics.
So, primarily started out geared towards laboratories.
So, importing data and getting it into the traceability system and getting certificates to clients.
However, it needed a good interface for the traceability system.
So, I essentially wrote a wrapper around the metric API.
And just to show you, it's nothing like fancy here. So, I essentially modeled this off of G spread.
This is just a random Python package that wraps around the Google spreadsheets API.
And I thought it was a good example of an API wrapper.
So, I modeled the metric API wrapper around G spread.
So, it's got a similar structure, but essentially it just leverages requests to hit the metric API.
So, just sort of...
So, Nick, real quick question.
As, say, a licensee in Oregon, are you allowed to use the metric API or do you have to go through a third-party vendor?
We can use metric.
Excellent. So, hopefully, this is a tool that you could just use right out of the box.
So, centrally, you'd authorize your metric client.
So, this just creates an instance of this client here.
And there's nothing really fancy going on.
It's just a class, and it just keeps your credentials as a header. So, it just creates a session, you know,
sets your vendor API key and user API key as the authorization.
Because I'm getting a sneaking suspicion that metric may use Python as their backend for their API.
Because they may not, but some of the responses I get are...
I'm not sure. Just sort of the way it's structured and just the way it plays so nicely with requests.
I don't know. So, it may not be, but it does play real nicely with requests.
So, all you have to do is set the authorization on your session with essentially...
So, this is essentially your username and password.
So, it's just sort of brilliantly simple.
And then the client...
You can interact with it in a couple ways.
So, you can either use the client to just, you know, do all your workflow.
Or the client actually returns to, for example, like if you're working with employees,
it'll actually return an employee model.
And so, if you want to sort of dig into the code, the models is a pretty informative place to begin.
So, the base model just sort of sets up a lot of cool functionality that integrates with Firebase.
But essentially, all of the metric models are represented here.
So, we've got an employee. We've got a facility.
So, the employee is a really simple model, just a full name license.
Then you've got the facilities.
And then, for example, this is how you're able to, you know, to leverage a lot of the functionality straight from the model.
So, you've got facilities. You have locations.
Strains. Items. Plants.
So, just to give you an idea, we don't have to scroll through the whole thing, but harvests.
So, you have packages. Patients. So, patience is on a state-by-state basis.
So, I don't believe all states have patience.
Nick, in Oregon, do you interact with, like, patients at all in the metric system, or is that just not really a requirement?
No, because we don't sell to patients. We sell to the retailer.
So, the retailer may, because we're on the manufacturing end.
So, we don't sell to patients.
All right. So, we know, yeah.
So, but there's, and here are some interesting helpers for you.
So, there's lab results, and then there's transfers.
So, these models could really help you out.
So, to give you an idea about how you would actually use some of the code, you can actually check out the tests.
So, if you go to tests, traceability, metric test,
this sort of walks through how you would actually use all of the endpoints, or at least the majority of the endpoints.
So, just sort of to walk you through this real quick, in case you're interested in using it.
The way I would recommend, you know, firing everything up is maybe, and you can have your own setup if you would like,
but I would, I mean, you may have your API keys on your server,
but in this case, I just have them in an environmental variable file, so a.env file.
So, you can just read in your credentials from the.env file,
and then you get your vendor API key and your user API key one way or the other, in a secure way,
and then you can fire up a client.
So, you can name it whatever you want, I just call it track, just for a nice short namespace.
And then, once it's set up, you can get off to the races.
So, you can get your facilities, and the reason that's important is you'll want to know the license number of your facility.
So, this example, you'll notice here we're creating locations,
and you'll notice that I actually pass a license number here.
So, you can either pass a license number every time,
if you have multiple licenses, and you need that flexibility,
or if you just have a single license and you just want to simplify things,
you can actually pass the client a primary.
Exactly, so you can pass the client a primary license.
So, that way you don't have to pass the license number every single time you're doing something.
But in this example, I am passing the license number just to show you how you can use, say, a cultivator's workflow,
and maybe a retailer's workflow down below.
So, long story short, you may want to check it out because you can initialize this metric client,
and then you can do everything under the sun with metric.
You can create your locations, update them, view them.
You can manage your strains.
So, this is sort of how you go about creating strains.
This is some functionality that may need to get worked into the actual client itself.
It may need to be implemented at some point because essentially, when you create, so here, when you create a strain,
in this case, I'm creating the new old-time moonshine, you're not returning the ID, unfortunately.
So, you actually need to do a quick get call on the strains to actually get that new strain.
And you'll notice that actually I'm not certain if you can filter strains by time.
I may not be able to.
But similar things with items.
So, you can sort of use this test case as an example of how you would go about creating items or just getting items.
Because before your manager gives you the green light just to start willy-nilly,
well, you don't want to willy-nilly do anything, but before you get the green light to start posting,
you can just start by just getting your inventory.
So, just get your items, get your batches, and then, you know, I guess your processors, you may not have plants or harvests,
but then you can get your packages. So, these will be critical for you.
So, that way, you know, you can just go ahead and get your packages, and that way you can get them into Python and start analysis.
So, you know, I'm sure you could put together some interesting.
Yeah, I'm sure you could put together some interesting statistics that could impress your boss.
And then finally, when you are ready to really ready to start with the workflow, then you can start doing transfers.
So, transfers are a little complex. And so, I'm interested to see how this would work in production.
So, if someone wants to start using the transfers in production, it would be quite interesting to see and maybe see how we could optimize it.
But transfers are a bit more complex in metric than they are in leaf data systems.
But it's approachable. So, essentially, what's happening here with the transfer is you've got your shipper.
And so, that's, you know, that's the person, of course, transporting it.
So, and then you, of course, need your recipient, that information about their license, and then you then, of course, add all the packages.
So, they may need to be a bit more efficient way than just passing into giant object.
But at the moment, that's the way transfers are created.
However, once they're created, because of the nice models we have here, you can, you know, you can update the, you know, you can update the transfers, you know, without much trouble.
So, you know, so this is sort of the tortoise and the hare philosophy where, you know, it took a little bit of time, you know, to write all those models.
But now they sort of pay off because especially the transfer ones.
So, basically, the majority of these classes have built in functions to create, update, and delete.
So, almost all of the class, all of the models, for the most part, have those three. So, that way you can just create, update, and delete a model just from itself.
Ah, yes, there was actually the client. So, the client has some helper functions to help out with transfers.
So, I wish I could print these out real quick, but I'll start wrapping this up because long story short, there's a lot of, a lot of utility functions you can use here to make your life easier.
You can get transfer types. You can get some, you can get all the transporters.
You can get a transporter's details.
And then, of course, you know, create, update, and delete.
So, I just sort of wanted to just sort of show you that real quick. Just to, you know, just to sort of tell you about this tool because,
you know, it's here, it's here if you need, if you want to use it, and it's designed to be simple and easy.
So, ideally, you can just toss in your vendor API key and your user API key, and you're off to the races.
So, like I said, it still needs, it still needs to be hammered a bit in production so that way we can figure out all of the interesting utility functions that can be added to it to make everybody's lives easier.
But it does function. It does successfully hit all of the endpoints.
So, it works. So, may as well put it out there and, you know, see if anybody can find it useful.
So, I guess before we move on, I guess, are there any quick questions about the metric interface?
No, you've done some really good work.
Thanks. And like I said, it's inspired by Gspread. So, really, really from start to finish.
So, I mean, so just to kind of show you some of the similarity here.
So, you know, see they just have their client, their model, their URLs, exceptions, and some utility functions.
And metric, same thing. I've got the client, some exceptions. So, just to handle the, you know, the base metric error, errors that are thrown.
And then, oh yes, and then the URLs. And so, when you initialize the client, actually,
sort of not shown in the demo, but you'll want to pass it your state.
So, the state is actually by default at Oklahoma, because that's, that was just where, like, K-NLitics was verified first.
However, so when you initialize your client, you'll want, when you initialize your client, you'll want to essentially use this snippet here.
Because the one in the example is sort of the simple, like the most minimal case where you just pass the vendor API key and the user API.
You'll probably also want to pass, you'll definitely want to pass the state equals to OR load case.
And then you may want to pass the primary license if you're just thinking you're going to just work with one license.
So, you know, nothing fancy there, just all the URLs.
And then there's, you know, a handful of utility functions, which these are just sort of things that sort of suit my fancy.
You know, for example, you know, just my preference for snake case. So, a lot of the package.
To basically metric a lot of their fields or camel case. And I have a hard time reading camel case.
I can read snake case faster. And so I just turn everything to snake case.
So if that's not preferred, you know, just leave some feedback.
I don't know. I feel like it makes things simpler. And then then it's all brought together here.
So the user has to go in and sort of manually
change all those fields or is there like a setup utility with like a user interface where you like walk them through what they need to set up?
Good question, Charles. So essentially.
This is designed to to maybe be plugged up to a user interface.
So this is more of an API. So this is well, this is a wrapper around the API.
So this is. This is essentially like a programming interface to the API.
So just. Just to basically make the API easier to use through Python.
But if you were essentially designing a user interface.
You would. You would still currently need to essentially pass some of these parameters.
So here actually the test case is a good example.
So in the user interface, you'll you'll need to collect.
You know, certain variables. So just to sort of show you. So, for example.
For locations. So here to create a location.
You need.
Well, the locations I've sort of tried to make a bit more efficient.
The locations you only need to pass in name and then it'll create that.
So the locations is actually a bit more efficient.
But the strains, for example.
At the moment. This object is essentially what you'll want to pass from your user interface.
So in your user interface, you essentially need some way for the user to enter the name.
The testing status. H.C. level. C.B.D. level.
Indicator percentage and sativa percentage.
There.
The models actually have.
A from method. So.
So for any model, so you could, for example, you could essentially do strain.
Great from Jason.
And you'd pass it the client.
Your license number.
And the object.
And then this object can be in.
Camel case or snake case.
But it's still once again, you're still needing to pass it the object.
So.
To answer your question, Charles.
You still need to get this object from somewhere.
So.
From my experience, just if you could boil the user interface down to just passing Jason objects, then it makes it quite pluggable because now.
Anyone can make any sort of user interface, right? You could use like, you know, you could use any JavaScript framework you wanted.
You could use.
Yeah, exactly. So you could use letter.
You know, so there's some other alternatives, but essentially any JavaScript framework.
And you'll just basically have a form where you just have the user enter their name.
And then these other fields.
And then you would just pass your Jason object and then here in your code and your Python code, you basically just get your strain and then you can just.
Pass that strain to your client.
So.
Why even do this? Well, it's basically just so you, you know, you don't have to.
Wait a second. Let me just navigate.
It's basically just it just supposed to be just a nice shortcut around having to do this every time.
So basically.
The benefits to the client are it creates a session.
So that way you've got essentially this open.
You've got like a connection established between your.
Piece of software and metric that way your requests.
You know, can go as fast as possible and then.
And then it essentially just wraps, you know, a bunch of helper functions around the request.
Because basically you're not doing anything fancy here. You just you're making just a record. So this is.
It's a big complex, but it's basically you're basically just making a request to that.
Let's open it over.
Okay, the client. Okay, so the requests. Okay, so this request is not really that much different than essentially just saying import requests.
Essentially you're just essentially you're just doing import requests.
You know, requests. Get.
You know, your URL.
Basically, just doing that, and then you may pass it some parameters.
So your parameters.
That's where you actually.
You actually can pass filters, and so that would.
And.
So, like, for example, a metric one, I think they've got like something like last modified.
And you want to double check this.
Anyways.
So, I'm going to put some filters in my test case.
You may try some of these filters.
So, you're basically you're doing that, and then you're saying.
So this is essentially would be like the simplest way to make a request to the metric API, you would.
You know, you would basically get your endpoint.
If you were just like trying to get started right out of the box.
That's essentially you wouldn't even you wouldn't you wouldn't even pass it parameters.
So.
That would.
Yes, and so.
That would essentially give you your response. So this would basically be.
You know, your simplest request to the metric API.
And then, you know, your data would be, you know, your response.
And then, you know, with this, you know, with with like, you know, less than 10 lines of code. I mean, honestly, about five lines of code, really.
Yeah, so with like five lines of code, you know, you can make a request to the to the metric API, and there's nothing wrong with that.
That's an awesome way to go when you're getting started.
When you're, you know, you're you're actually, you know, setting up your user interface, you know, you're going to maybe.
Find you're going to be repeating some things. So, for example, some try and accepts.
So here, you're this is sort of restarting the session if the session ends and then down here, we're checking the response because.
When you get in next week, I want to get the green light that I can actually show you the test environment in.
In action, so I actually want to check with metric if I'm it can actually demo the test environment or not.
I'm not certain I can. That's why I'm just showing you the code for today.
But next week, I would love to show you this in, you know, in action, so to speak.
But I just want to get the green light first.
That I may not so, but long story short is real quick, like, you know, you can just get the response.
You know, you can check its status code.
So that'll raise an error if if you didn't have a 200 status code, but essentially.
Essentially.
This is sort of just how the client grew, you know, basically, you know, you start with just this simple import requests, but I just sort of knew that this was just going to be, you know.
You know, just a simple wrapper around an API. So you're just going to need some some basic things like, you know, a session just to be efficient and, you know, some try accepts.
And so that way you just have this built in exception class.
And this is it's just basically a cop copied this from G spread, but it's basically just a fancy way to get the error message.
So.
So basically when metric errors out, you know, they may give you different types of error responses. And so this is just a fancy way to handle all the cases that way you can get a nice error message printed out.
No matter what the error is.
And then just and then it just, you know, returns models. So that way.
The models are an attempt to be sort of self sufficient. They're not entirely, but you can think of the models as souped up dictionaries. So they're basically just dictionaries that can also, they also have a couple built in methods.
So they basically can self update and self delete.
So that's that that's the main thing. And just from a programming point of view, it can be useful because so here, this is still a long answer to your question, Charles.
But basically in your user interface, you've got your form, where you create the strain.
This is done on your back end, where you basically just get the strains ID and save it in your database.
And then on the user interface, if say you then, you know, change one of the form fields. Well, then you just, you know, just run this function on your back end and it just updates the strain.
And then if they like click the delete button, you know, you could say they called the delete button. You could just do, oh, you know, we want to do.
You know, you can just you can basically just self delete these things.
So the long story short is primarily meant to be used, you know, programmatically.
So whether you plug, you know, plug this package up to your user interface or you just want to, you know, just write some scripts and you just you just need a helper.
I've just found this. I just found creating abstractions quite useful because so let's let's take it all back to the ground floor here here in the end.
Because what are we trying to do? We're trying to make your workflow as simple as possible. So we just looked under the hood.
And so don't, you know, don't be scared or anything. Just look at G spread. I pretty much just copied the work there and
it ended up being a little complex. But, you know, as far as rappers go, it's it's not the most complex rapper in the world.
I try to keep it as simple as possible. And then.
I've just found that creating rappers helps in your workflow because then you can just you can abstract away all that complexity.
So this is actually a programming philosophy that I've learned recently is you want to you want to program to an interface.
So this is an interface, the metric. So we're basically all we're doing is saying, get plans, you know, manicure, harvest, move.
You know. Get packages, get receipts. So there's no logic here. That's our interface.
And then. This is what's called our implementation. And so this is where we've actually implemented our request to the metric API.
And so our interface doesn't care about our implementation. So it's brilliant because you can set up your, you know, your user interface facing code.
So that way, you know, you just call it get packages. But let's say, you know, get packages needs to be improved or refactored.
Well, you just go and. You can, you know, you can.
Fix or improve the implementation of get packages.
But then everybody who's using get packages to say you're using the CanLytics module, then you don't have to change anything. You're good to go.
You can update to the next version and everything just just still keeps working.
You know, so we can, you know, if we need to fix an error, you see here we're doing some error catching, you know, in case, you know, some basically this catches it in case.
Oh, does it return a list? Does it return an object or does it return nothing at all?
And so, you know, say we need to add error catching to create packages later. Well, we can change the implementation and then the interface stays the same.
So that's sort of a design pattern that I've learned recently, and it's been incredibly effective.
It just makes writing software a dream. And next week I'll show you the the CanLytics console, which is actually trying to do what I just described, which is take
this engine, which is an interface, a programming interface to the metric API, so an API to an API. But next week I'm going to try to show you how I've plugged it up to the CanLytics console.
So that way users actually can enter in their strains and everything. So next week, perhaps, I can show you how instead of doing strain creation and management or package creation and management
programmatically, we can basically wire this up to a user interface.
Any user interface, so you can make any HTML, JavaScript, Flutter, Dart, Android,
iOS, anything, right?
Well, those may not be running Python, but you can plug this up to any user interface.
Well, in those cases, you would just be making requests, but plug it up to any user interface and you're off to the races.
So I just thought I would share that with you today. I know we were going to talk about statistics, so we may have to get back to that next week, because they also have some really cool data that Charles has put together on
Waste Analytics.
But I think we're out of time for today, so I can show you more of Charles' awesome work next week.
So just to wrap up today, are there any final questions, comments, thoughts, or anything?
Now, I do need to go back and fix a couple of the, I think a couple of things in that import code, but at least make it more efficient.
Yes, and that's where you've hit on the important principle of refactoring, where, I mean, that's the way software goes.
I mean, let's think about how far computers have gone. You basically just need to start somewhere.
So you just need to start with some code that works, right? So you wrote some code that imports that laboratory data.
So awesome work, Charles. And so, as you noted, it can get hightied up, it can become more efficient, and it can gradually be improved.
And that's what you always have to be doing to your code is just keep improving it, keep refactoring it.
And that's how your code evolves over time. And so, but you have to start somewhere.
And so thank you for making those contributions. And so, Analytics now has its first contributor.
So thank you, Charles. And we're excited to really, you know, really, you know, this is really speeding up. So it's really exciting.
And, yeah, it's exciting to put these tools out to try to be helpful.
And, you know, we can all tinker on it. So if you're open to it, I may actually maybe adjust some of your comments and things just to sort of fit sort of the style of the project.
But I think the code looks good and functions good. So if you want to tinker on it any more than by all means, but I just want to really thank you, Charles, because that is a huge contribution.
Like I said, that's one of the most valuable things for laboratories is to be able to get that data and import it into your into the laboratories database with the click of a button.
No data entry.
Click a button. All that data is in your system, ready to go. You know, let your analysts spend time doing science, not doing data entry.
Yeah. Thank you for contributing to Cantilex, Charles.
Great. Well, we've run a little long. So I'm going to go ahead and wrap it up here just
just so I don't keep you all day. But thank you for coming and checking out the latest the latest developments on cannabis data science.
Are you crew. Thank you.
Feel free to reach out through email or or messages if you know you have any thoughts or or Nick if you start to use it and you run into any questions or anything just reach out because I want to get this this tool in your hands so you can find find some use for it.
Yeah, we'll do.
Great. Awesome.
Alright, everyone, until next week.
Okay.
Last one.