Have you heard of Kedro? It's a Python framework for creating reproducible, maintainable, and modular data science code.
We all know that reproducibility and related topics are important ones in the data science space.
The freedom to pop open a notebook and just start exploring is much of the magic.
Yet, that freeform style can lead to difficulties in versioning, reproducibility, collaboration, and moving to production.
Solving these challenges is the goal of Kedro.
And we have three great guests from the Kedro community here to give us the rundown.
Yatunda Dada, Waylon Walker, and even Donov.
This is Talk Python to Me, episode 337, recorded October 1st, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy, and keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.
This episode is brought to you by Tab9, the editor plugin that enhances your autocomplete by learning how you write code.
Us over at Talk Python training with our courses.
And the transcripts are brought to you by Assembly AI.
Yatunda, Ivan and Waylon, welcome to Talk Python to Me.
Thank you so much for having us.
Yeah, thank you for inviting us.
Yes, thank you.
Yeah, it's fantastic to have you all here.
Let's start with just a little bit of your background.
Since there's three of you, maybe not too long, but how do you all get into programming, Python, into this Kedro project and so on?
Yatunda, you want to start with you?
Sure.
So I'm a principal product manager on Kedro.
I've been with the project for actually exactly today, three years.
Oh, nice.
Three years and eight months.
You've been there most of the time.
That's fantastic.
Yeah.
Ivan has been there from the beginning, so he'll talk about that.
My background is mechanical engineering, and I would have been a user of Kedro.
We discovered, I think, one of the coolest user interviews I've ever done was with my former team.
They picked it up on their own, which is amazing.
Oh, nice.
Ivan now.
And I work at Quantum Black.
That's the primary.
Yeah, okay.
Ivan?
Yeah, so I'm Ivan.
I'm a tech lead for Kedro.
Started, like, have been working with Quantum Black for the last almost five years now.
Is it?
Yeah, five years.
So you've been there from the beginning, as we hear.
From the beginning for Kedro, not for the beginning.
Yeah, yeah, yeah.
That's what I, yeah.
Quantum Black.
Yeah.
So initially, it was a small internal tool that was being developed by another two people on our team, Nikos and Aris.
And then we decided to turn it into a product.
And then we started from scratch and developed it into what it is.
Then we found out that things can get serious.
And then that's how we hired Yetu, because we needed a PM as well.
As a proper product.
Otherwise, my background is in software engineering, all kinds of software engineering.
Started off as web developer.
I was very keen to do some game programming before that, but I couldn't find jobs related to that.
A lot of people are interested in doing game programming until you actually get into the reality of it.
And the reality is, a lot of times it can be a grind and it's hard to get a job.
I was going to say that I'm quite lucky that I didn't end up being a game programmer.
It's not the first time I heard that.
That's right.
Yeah.
So then, yeah, I moved on to distributed systems and I ended up doing data and AI at QB mainly.
So I'm kind of a newbie in the data field, but being there for five years, kind of newbie.
A lot of people are in that realm, right?
A lot of people are coming into the whole data science side of things.
Waylon, how about you?
My background is in mechanical engineering.
Probably around 2014, I started diving deeper into the data side of things.
I had some family medical things that came up and it kind of severely limited my ability to travel.
And slowly over time, I just kind of doubled down into the side of things.
Yeah.
It was right around the time you started the show.
And a lot of what I've learned has either been directly from this show or from like taking ideas from the show and diving into them.
Oh, awesome.
That's really cool.
Happy to bring that to you.
I think a lot of people who come from backgrounds that they're not like traditional CS backgrounds, right?
They're kind of coming in through a side channel.
I feel like the podcast has offered a lot of connection and extra information besides just what's on like the docs page of some projects for people, which is great.
It's awesome to hear.
So now I'm a team lead for a data science team and do Python every day.
And we use Kedro pretty heavily in all of our projects.
So before we move on to the topic, give me a quick thought on comparing mechanical engineering work life experience to software development, Python developer experience.
How do you feel about where you are?
I like where I'm at.
One thing that I kind of struggled with in mechanical engineering was there was a lot of learning in college.
There was a lot of things to learn.
And then you get an industry and everything's kind of like walled off.
And the learning doesn't completely stop, but it's very hard to do.
You know, on the software side, a lot more things are open to learn.
There's a lot more resources that are just out there in the open and not like behind proprietary IP patents and all that kind of stuff.
I think that works really well for me.
I'm a learner.
I don't remember the, is it Galt?
The personality study kind of things.
Yeah.
Always come out with learner is like the top thing for me.
Nice.
Yeah.
So it's a good fit.
Yeah.
If you don't like to continually learn and continues, continually kind of reinvent yourself, then software is probably a data science is probably not a super awesome place because the life cycle of these things.
I mean, if you want to take it to the extreme, you could do JavaScript.
But most of us, we have like at least a year on the technology before we move on.
Yeah.
All right.
Now, speaking of that, let's go ahead and get into our main topic here.
And I want to kick this off by talking about reproducible and maintainable data science.
So a little bit like engineering, people are coming to data science from these different angles, a lot of times from computational stuff, from biology or from finance and economics or whatever.
And they don't necessarily come with a full baked set of, oh, here's the software engineering lifecycle skill set.
Here's how I set up my continuous integration.
Here's my testing.
And like a lot of times it's like, look, I got it working.
We're kind of good.
You know what I mean?
I think one of the areas the whole data science field is working with is taking a lot of these folks who are coming from non-traditional CS backgrounds and helping them create more reproducible, reusable bits of code, notebooks, maybe even code outside notebooks.
So let's maybe open the conversation there
because that's where Kedro focuses
on helping data scientists create reproducible,
maintainable code.
Eutunde, do you want to maybe kick us off
with some thoughts on where Kedro's philosophy is on this?
So I guess if we actually break it down,
it's a Python framework that helps you
do those specific things.
And when we talk about it being a framework,
it's kind of embedded with best practices
and ways of structuring how you write code
so that you can get those reproducible,
maintainable, and modular data science code.
But if I go into each one of the definitions,
when we say reproducible, we kind of mean that
when I rerun this pipeline or rerun this experiment,
I should get the same result at the end.
So there shouldn't be any real surprises
that things have really changed or things are really breaking.
When we talk about it being maintainable,
we now also add in an aspect of collaboration,
even for yourself, that if you come back to this code base
like three months from now or six months from now,
you should be able to know what was going on in it
and be able to modify and tweak it.
And other people should be able to do that with you too.
It's not really, it shouldn't be the biggest disaster
if the main code contributor has left
and you now have to try, scramble to figure out
what's going on there.
And then when we talk about it being modular,
this is where we encompass some of the software engineering principles
that you wouldn't ordinarily learn in,
maybe if you enter data science from the mathematician space
or even from the sciences,
where we think about you being able to break your code base down into small units
so that it's possible to think about things like reuse,
but also it's easier to do things like testing the code base as well.
All of these things like basically amount to
trying to enforce like software engineering best practice,
especially where you recognize that you might need help with that.
One of the other areas that I've seen a lot of emphasis on the project about is collaboration.
And one of the things that can be challenging is if you're a data scientist working on a notebook,
you might run some cells, maybe on data that is live.
And so the data might be slightly changing.
You check that into GitHub or source control.
You've got the results in sort of a scrambled up JSON file notebook,
and then someone else has rerun it at a different time,
and then they try to check it out.
Well, you know, you end up with these conflicts and other issues.
So the sort of natural flow of,
hey, let's just check everything into Git,
and then we'll just synchronize over that
can sort of fall apart with some of the traditional tooling of data science.
And that's definitely true.
I think Kydra's origins actually come from large teams,
upwards of like at least three or four data scientists and data engineers,
machine learning engineers collaborating on the same code base,
upwards of, you know, to 12 people having to work on the same code base.
If you're using Jupyter Notebook and trying to construct your entire pipeline in it,
I think the workflow would look kind of strange with you waiting.
Maybe Waylon has some comment on like watching this in practice of,
you know, waiting for someone to finish in the Jupyter Notebook
before you could have a go at it and try your things.
During our engagement with McKinsey,
we were introduced to Kedro during kind of the first iteration.
Yeah, and Waylon, by the way,
we've only talked about Quantum Black so far,
but Quantum Black is like a subsidiary of McKinsey.
So yeah, right.
This is all sort of the same organization in a sense, right?
So that's why this is coming together, yeah?
Yeah, good point.
But so the second half,
they chose like just due to familiarity,
the people that we had with us,
it was their first time using Kedro.
And they're like, well, if we want to move fast on the second half,
let's not try to do anything new.
And let's just do notebooks like we always had.
Right, fall back to what they know sort of thing.
Yeah, and the workflow there was definitely like
three people are on a project,
two people are sitting idle
while one person has the notebook checked out.
Oh my gosh.
That sounds like old school source safe type source control.
Someone's locked the files, no one else can edit it.
Like that's just, it's completely 1990s style, right?
But it's a real problem.
I mean, some of these things are,
there's an attempt to address them
by having collaborative notebooks,
basically Google Docs type of experiences, right?
But usually those are in somebody else's cloud,
somebody else's compute cloud.
And so you're taking the trade-offs
of running it over there, right?
Yeah, and there's multiple things
I think you're missing out on.
When we talk about even making a robust code base,
writing unit tests in a notebook,
writing doc strings in a notebook
becomes a little challenging.
And then we think about all the additional tools
that you have to add for collaboration.
How am I going to do pull requests
and review my friend's code?
Because we know the way that
when you check in a Jupyter notebook,
it's often with the weird Jason thing.
So how do I do reviews of my team members' code
so we can overall improve the code base?
And then some of the features as well
within notebooks like cache state as well
cause issues down the line
because I might be working on a version of my code
that when I rerun my entire Jupyter notebook,
not everything will run.
So it's not necessarily down with the notebooks
or anything, for sure.
We believe that there's a space for them really
for maybe doing exploratory data analysis,
trying to work out what's going on with the data set.
There's space for it
with initial pipeline development as well
if you're still prototyping
and you're not sure how things are going to go.
And then even for reporting maybe,
if you want like a more visual interface for reporting.
But when you talk about like code
that I want to be able to run in three months,
six months, and many people will be using,
it has to be in Python script
and it's supported when it's in the framework.
Yeah, I think that's a good point.
You can definitely start in the notebook space
and then eventually move it over.
Now, one thing I do want to give a shout out to,
I don't remember the name,
but you can set up a Git pre-commit hook
that will strip out the metadata,
the results of your notebook.
So that's kind of a fix,
but it's still, you know, it's not that amazing.
The other thing, you talked about reproducibility.
One of the things that troubles me,
and I'm a fan of notebooks and I like it.
And I just on Python Bytes podcast,
we just talked about how JupyterLab
is now a desktop application.
they just released that like this week,
which is really cool.
So there's a lot of neat stuff
happening around notebooks.
One of the things that I'm not a big fan of though,
is the ability to reorder execution
or only execute part of it, right?
There's a lot of benefits to say,
run the cell that computes the data
that's really expensive.
And then run this,
no, make, go back three cells,
make a change here, run this one,
and then go back down four cells and run that one.
And it's kind of like a go-to with no explanation.
Right?
Where you can jump around in different orders.
And that certainly doesn't lead to reproducibility
when it's up to the human's decision of like,
I decided I felt like I wanted to make a tweak
and rerun that one.
And I forgot to run the intermediate step that used that.
It's very problematic for long-term reliability,
reproducibility, and so on.
There's quite a few studies, I think,
where people have tried to rerun notebooks.
There's one by NYU, I think back in 2020 or 2019,
where they rerun like,
I think over like 80,000 notebooks.
And only 24% of them completed without error.
But there's a very small part of that
that had the same result
when the notebook was finished running.
Yeah.
Wow.
Very interesting.
The other part that Kedro has is the versioned datasets.
So not only like just running the code itself,
but you can check out like an exact version of the code
or the version of the data that was ran last time.
Okay.
So you sort of store the data as well?
Like instead of just versioning just the source code or the notebook,
you also version the data?
Yep.
That's an option as you're creating your catalog entries.
You can, it's as simple as just putting versioned equals true
pretty much on most of the datasets.
Oh, that's really cool.
Ivan, how about your thoughts on this reproducibility,
maintainability side of data science?
That's essentially why we started Kedro
because here at QB, when we were going to clients
and we needed to be able to,
if anyone has worked at Consonance,
you know that sometimes you need to rotate people,
you need to move people from one place to another.
And the pace is quite high.
And when people end up in a, like in the midway,
like in the middle of a project,
there is quite a long onboarding time,
which is probably a week or more than that.
And that's super expensive for a client
to pay for one extra person
just to read the code that was written to that point.
Moreover, when you hand over code,
it can be just notebooks.
So we ended up resorting to,
okay, having different stages
where you do things in notebooks,
then you need to convert them
in another programming language.
And then you have an extra person doing that.
And obviously that conversion wasn't done
due to the limited time in the best way possible.
So it was quite hard to have this,
you know, workflow of making a reproducibility
reproducible code without sacrificing speed and agility.
And out of that need,
that was how the initial versions of Kedro were born.
I think notebooks are super useful as well,
like, but they are definitely not for production code.
They're for exploring,
for trying out, doing some different things,
just basically a working session.
And I like the name notebook
because it's essentially,
you're just catching things in a notebook.
The thing is that what we see is people end up
using those in production.
And I think that makes it hard.
You already explained,
like all of you mentioned some of the issues.
How do you manage that?
And how do you deal with credentials,
with traditional stuff?
And for me,
when I was coming from different software background,
joining a data company,
and I was like,
where are the frameworks here?
Like there was no frameworks.
Everything was platforms.
And there was no way for you to start a project.
And I found that super interesting.
Interesting.
Not like cookie cutter type of templates
and those kinds of things for generating it.
Like here's how we integrate
with all of our other libraries
and infrastructure and just go, right?
Yeah, that wasn't there.
And it was quite hard to align on a similar process.
And it reminded me a lot
to early days of web development
when everyone had their own PHP scripts
that they would make
and people didn't use frameworks a lot.
And then things moved on from there.
And for me, that's how it felt.
This portion of Talk Python to me
is brought to you by Tab9.
As you know,
I'm a big fan of rich text editors
and all they can do to empower us
to work faster and smarter.
The most important feature there
being autocomplete
to help you write code more correctly and faster.
So why not supercharge your autocomplete?
If you haven't tried Tab9,
you should definitely check it out.
It works with PyCharm, VS Code,
and even Vim among other text editors.
Tab9 is kind of a mind reader
that gets even better as you use it.
Tab9 uses three AI models,
an open-source trained AI,
a private code-based trained AI,
and team-trained AI.
A very cool benefit of Tab9
is the fact that they have a team-trained AI.
So if you're on a team working on the same project,
you can all work on the same model
and get suggestions accordingly.
The more team members you add,
the faster the AI will learn your project,
preferences, and patterns.
Tab9 is free to use.
They have a free forever subscription plan
as well as a pro plan
with advanced models,
an enterprise plan for larger organizations,
and every plan supports inviting team members.
If you're a student, Tab9 is 100% free.
Just let them know you're a student,
and you'll get the pro plan for free.
See what better adaptive autocomplete can do for you.
Visit talkpython.fm/tab9 to get started.
That's talkpython.fm/tab9,
or just visit the link in your podcast player's show notes.
And thanks to Tab9 for supporting Talk Python to me.
It was very interesting.
I think it was very interesting initially
because of this, like,
okay, how do we bring that
to people whose job is not to build software,
but their job is to build models?
And these are different skill sets, right?
It talks about how there's these skills
that data scientists should learn
from software development, software engineering,
and that's true.
It would help them a lot,
but there's also a lot of skills
that data scientists and people in engineering
and economics and biology that have,
as software developers like you and I,
you know, we don't know the inner details
of, you know, gene editing or mitochondria or whatever, right?
Like, there's a, to be fair,
I mean, it's not like to put them in a negative light.
It's just some of these skills
are not learned along the traditional path,
and so it does make things like reproducibility hard.
Yeah, that's why I think the data is like a very,
you know, the data landscape is a very nice place
because it's a very creative mix of people
from different backgrounds for that reason.
And I think what software engineers can do is,
okay, help those people to be the most effective,
the most productive with what skills they already have.
Yeah.
And maybe just teach them
just enough software engineering practices
so they can go ahead.
They don't need to be experts in two things.
Yeah.
You can never be like full expert in,
you know, software engineering and then biology
and, you know, DNA and all that.
And if we go that way and require people
to be full-blown experts,
that's, I think, the wrong path.
These are ways just to equip them with the tools.
Especially in Python.
Yeah.
The ethos of Python is that it's kind of,
you can be very effective
with a partial understanding of what it is.
You know, and if you require them
to be full data scientists,
then it's, you know, something different for sure.
Yeah.
So let's talk about Kendro specifically
in terms of not just the philosophies
and some of the goals,
but, you know, what is it?
When I first heard of it,
I thought this feels a little bit like,
you know, one of these data pipeline type of programs,
you know, like Luigi or something like that.
But that's not quite right, is it?
You tuned in.
No, it's not quite right
because we really do dial in on that focus
of like software engineering best practice first
implemented on code.
So we think about things like a project template
for you to know where to store
different parts of your code.
I actually think then we've also got a data catalog
which manages like how you load and save data.
We've also got a way for users
to interact with configuration
for the first time as well.
So removing what would have been maybe configuration
because of their loading and saving paths
for data out of the code,
as well as things like removing parameters
and even implementing logging.
And then we also think around
being able to have our own pipeline abstraction as well,
which is why everyone gets excited
and thinks that Kendro is kind of like Luigi Airflow.
I think we get grouped with Dagster as well,
all these different pipeline abstractions,
but we really do focus on that journey of like,
how do we even write code that's worth deploying?
Which is a kind of like a different focus
because when you get to,
our expectation is like when you get into Prefect,
Dagster, Luigi, Airflow,
you really have a code base that's worth deploying.
And you just really need to think about like,
I want it to run at 7 a.m. on Monday.
Right, or based on this trigger
when a file shows up in blob storage or whatever, right?
Yeah, which is a completely different focus.
And we think that we call that group,
the orchestrators are really good at what they do.
But in terms of that whole process
of leading up to a code base that's worth deploying,
that's actually what Kedro handles best.
Yeah, cool.
You guys want to add anything to that?
Maybe you might can go a bit more into like functionality.
Yeah.
What it has to do.
I think I can't add anything after you get to this excellent introduction.
I think initially that's the main thing we were asked for.
It's like, oh, why don't we use Airflow instead?
And we're not exactly the same.
You can just use Kedro and Airflow together.
And in fact, actually now we have a plugin because we connected with them
and it was a very nice collaboration we had.
But I think just to underline the main difference is,
you know, like all of those tools,
they came out from big tech companies that already had good processes.
Yeah.
Like, for example, Luigi comes from Spotify and so on, right?
So Luigi from Spotify, Airflow from Airbnb.
And like, those are big tech companies.
They have uniform, like,
or at least they have a big team that is taking care of the infrastructure.
So you own the infrastructure, you own everything.
You just need to put it there,
like run your Airflow instance and then run your code there.
And for us,
we come from consultancies where
you don't know what infrastructure you'll find at your client.
So there is no way for us to say,
okay, this is the scheduler we're going to use.
And it was really impossible.
Yeah.
And you also don't know what sort of team you're dropping into.
Is it a large, highly professional, experienced software team?
Or is it a bunch of research scientists
who need a little help on the software side, right?
Yeah, absolutely.
Also the team, you don't know any of that.
And the thing is that
we need to have some transferable skills within our teams
when you work on one project here and there.
So the next time you're more efficient and more productive,
even though you're changing project.
And that's the main difference here
with Kedro and those orchestrators
that like we don't have that assumption on the infrastructure.
As yet to mention,
it's like we focus on how to make something that's worth deploying.
And then once you need to deploy it,
at least that's very hard to achieve.
But this is what we strive for
is to make Kedro deployable basically anywhere.
If it's managed service in AWS,
or if it's Airflow or maybe they're offering,
they have an astronomer offering,
which is basically managed Airflow.
If you need any of that,
Kedro should be able to run on all of this.
But during the development process,
you don't need to, you know,
use their primitives to create your nodes
and deal with all the, you know, the extra work.
The data scientists or data engineers,
they don't need to care about,
okay, what is an Airflow operator or these kind of things.
So does this mean that you're able to swap out
these different data pipelines?
Like if, for example,
I had a company we started on Luigi
and we're like,
oh, we really want to move to Airflow.
We'd written our stuff in Kedro.
Would it make that easier?
Yeah, I would say yes.
Okay.
Depending how you've written it.
I guess you can always make code not portable, but yeah.
You know, one of the options
that hasn't been mentioned yet is the one we're using,
which is just the Kedro Docker plugin.
So Kedro works very nicely inside of Docker.
Despite all the nice orchestrators out there,
there's also the backup plan of just put it in Docker
and that can run virtually anywhere as well.
Yeah.
Sometimes that is really nice.
Just, I know there's all this stuff as a service
to help me out,
but we'll just go in the simple route
and run in it this way.
All right, let's talk about some of the features.
And Kevin, you talked about the lack
of some kind of template to get started.
And that's the first feature listed here.
So maybe tell folks about this.
I think that was probably the first one we implemented
when we were rebuilding the thing.
Because what we found out is like lots of data scientists,
they were naturally using like some cookie cutter templates.
Yeah.
Okay, this is my project.
This is the structure I like.
And then we had a big discussion
with many different data scientists
how to implement this.
So we set out on a,
the thing that will be the bare minimum
that you will need for starting a project.
Right.
The minimal set that everyone is going to use.
One of the things I really dislike about templates,
these types of project templates,
and I see them all over the place,
is, oh, here's how you use this template to get started.
And the template says,
okay, what we're going to do
is we're going to set up Celery as your backend worker.
We're going to set up Postgres as your database.
We're going to set up SQLAlchemy as your data layer.
We're going to set up X,
and you end up with 10 things.
You're like, I only want four of these,
but the four it's helping with is really useful.
But then I got to hunt through and get the others out.
And it's just,
you do want to aim for this minimal side
because, you know,
while it's nice to have support for the other things,
like if you foist it upon people
and they're like, I just,
this is more junk than I,
like I'm using less than half of this.
So this is not useful for me.
Right.
Yeah.
So that was your philosophy to go more minimalist on it.
Yeah, absolutely.
Even though,
because at that time it was an internal tool,
we had some stakeholders that we had to appease, right?
Like there was,
we had internally a very well-developed
data engineering convention.
And then they absolutely wanted to have the,
you know, in the template,
we need to have the folders
with those layers in the data engineering.
And I think you can still find that in Kedro.
So there are these kinds of things that we needed to do,
but they're not necessarily,
okay,
you don't need to use them,
that you can remove a lot of those.
And further down the line,
we ended up introducing something called starters.
And this is essentially,
you can have a custom template that you can start from.
And people are using them to create their own custom projects for their organizations.
Yeah.
I think that's a great idea.
Yeah.
And we're using cookie cutter behind the scenes,
which means like another thing that we wanted to do is to not reinvent the wheel
and use standard tools out there.
If the Python world is using cookie cutter,
there is no reason for us not to use it.
Right.
And we went with that.
And that's how we settled on the template system.
Yeah.
Nice.
And you talked about,
or Hedro talks about on the homepage,
how it uses the cookie cutter data science,
cookie cutter template,
which is a logical,
how much of that is that?
Or have you kind of moved beyond that?
I think we moved beyond that.
It was mainly,
that's what the inspiration was.
Ah,
got it.
It's not like we're using it,
but more like it was inspired by this because we found out like a few users back then,
they use that one.
And it was fairly sane.
I mean,
if you,
if you don't need to framework,
I think it's quite a good starting point.
So if you don't need a full blown Kedro setup,
I would recommend that one.
And,
uh,
we said,
okay,
how can we build upon that?
And like make,
obviously we started from scratch,
not copying any of their templating,
but saying,
okay,
this is a very good example of what we can be.
And then how can we achieve the same thing,
but achieving our goals for making this framework.
And,
uh,
that's how we,
we settled on.
And I think we,
we still honor it because,
uh,
I think it was a good inspiration for us in our documentation.
Yeah.
Very nice.
I love it.
And definitely thumbs up on using something like cookie cutter,
right?
There's already so many templates out there that people are using.
People are somewhat familiar with the idea and they maybe know how to extend it.
Right.
So no need to go write your own macro language or something crazy.
Yeah.
All right.
Next main feature is the data catalog.
One thing I was going to mention here,
Michael mentioned that you get like from a template,
a lot of times you get a,
a thing that's got everything that you need.
And then a bunch of stuff you don't need.
I think one thing that plays well with Kedro is this catalog.
So with the catalog,
I can kind of,
you know,
abstractly tell Kedro where my data is and what type it is.
So that catalog can load things from pandas,
spark,
desk,
from databases.
There's pretty long list of data sources that it can load from.
So I don't need to change the template based on what my underlying data is or where it's stored.
That's really nice.
A lot of times when you're thinking of data,
the abstractions are you can switch between MySQL,
Microsoft SQL server and Postgres,
not between,
you know,
spark and a relational database or cloud storage or something like that.
That's a lot of flexibility.
One really nice feature I like that was added in the 16 series is it's built on FS spec under the hood.
So you can have data sitting on S3,
GCP or your local file system.
And all you do is change your file path,
maybe like a slight tweak to your requirements.txt.
But other than that,
Kedro just knows how to load data into whatever object type you ask for.
Yeah,
very nice.
Also helps on the data science side,
if you're not super familiar with like remote blob storage APIs,
you don't have to learn that,
right?
Which is good.
Cool.
And another thing to maybe mention is if you don't need the full Kedro template,
you don't need the pipeline and everything,
you can use Kedro's catalog by itself.
Okay.
So maybe if you're just starting a notebook or just starting a project in a notebook,
you might want to move it to Kedro later.
You can start putting your catalog together as a Kedro catalog from the start.
Nice.
And then maybe as you move it more into source files,
it's like part of that's already done,
right?
Yep.
You're closer to the destination.
Yep.
And you can use their loaders and savers so that you don't have to write any sort of
saving and loading code manually.
Yeah.
All right.
Next one is pipeline abstraction,
automatic resolution of dependencies between pure Python functions and data pipeline visualizations.
And you all have a cool visualizer there of a whole lot of stuff going on here.
I could zoom in here,
but like this,
this really interesting visualizer of what's happening.
who wants to sort of tell us what this one's about?
I'll happily take this one.
And I leave the coding starters to yet.
I really wanted to take that one because I want to kind of promote using more the API of the pipeline.
I think this is probably one of the best things we've done.
And it was kind of a find that we had is what is the pipeline in our,
I think that's probably one of the things that makes Kedro different than other tools.
We treat each processing node as a pure function.
So what you need to do is just to write a pure function that you have inputs and outputs,
and you return stuff and that's all you need to do.
And then you need to announce that in a pipeline that,
okay,
I'm going to use that function.
we'll have those inputs from the catalog that Waylon was talking about.
And they're just aliases to,
to those references in the catalog.
And then when I'm done with that function,
then I'll save them to those datasets.
And you don't need to know,
okay,
what's the order of execution or like any of that.
You just need to think locally.
You need to think about that function you're dealing with.
Okay.
I need maybe in this example that we have on the screen,
like people who are listening,
they might not be able to see,
but let's say you have an input to a function and let's say factory train.
In that example,
we have,
and that's your input.
And then you want to remove the new columns and that's your function.
And then let's say you have a,
let's say we call the output a clean factory input or what was it?
So that's all you need to think about how to solve that locally.
You don't need to think how that would fit in globally.
And then once you add enough of those functions,
then the connection,
those dependencies,
because you announced them in your inputs and your outputs,
they'll be figured out by Kedro.
And then,
you know,
this graph,
the visualization will be drawn for you out of your code.
And then you can use that for running your code in that particular order.
And why I say that we,
we are so proud of this because using these pure functions and connecting them as pipelines,
gave us a lot of ability to reuse code and reuse parts of the pipelines without really taking care of like where the data is.
So you just work on a pipeline level and the connections,
and then the data catalog would load and save things for you.
And,
and that,
that made it super,
super easy for us to,
to scale the types of projects we can build.
We started off with very small pipelines and now we,
we have maybe yet to can talk more about this,
but we have projects which have like hundreds of people,
hundreds of nodes internally in QB.
Yeah.
If you look at this,
there's a lot going on here.
And I really appreciate the idea of being able to just focus in on,
you know,
small pieces.
It brings me back to your idea of talking about,
well,
let's just write a .php file and put,
start just,
I'm going to start writing HTML and I'm going to start writing some SQL query and I'm going to write some more markup.
It's just all from scratch and there's zero structure and there's zero support.
So if you're going to do something like that,
you're doing it all at once,
all at the same time.
Whereas,
you know,
compare that to like a modern framework,
like Flask,
all you do is write the view method.
You don't care about how the template gets rendered.
You don't care about how the process comes in or finding the verbs to figure out.
You just,
I know when I get here,
Flask got me here.
I do the,
the five lines of code that I got to do and we're good.
And I feel like this is real similar,
right?
Yeah.
Yeah,
absolutely.
You just write a function.
Yeah.
You write a function that says unify timestamp column name,
or you write a function called remove null columns.
Like you can definitely do that.
That's not challenging,
but if you look at this overall workflow,
it looks like there's a lot going on here.
Yeah.
And I really liked that you brought that analogy with frameworks,
with view and like these things,
because the more we started building that,
the more it was very similar for me.
I mean,
I've done some Ruby on rails before and actually the pipeline sounded like the
roots file.
So you would have different routes like,
okay,
what is the,
how do you register on this URL?
This is the action I would call and actions here are our notes.
Right.
And what data is provided to it and things and so on.
Yeah.
All that.
So the data that's provided to it is basically,
you know,
the URL endpoints and,
and maybe the post data and things like that.
And then the output is your views,
for example,
in,
in traditional framework.
The only difference here is that your inputs and outputs,
their data,
they're not a URL data coming from,
you know,
the request.
And then the response is not a view,
but actually again,
saving to the data.
And there is one subtle difference here is that you,
you have dependencies between different routes where in web frameworks,
they're fairly independent,
right?
It's a stateless thing.
Yeah.
We're here.
We kind of,
it's still stateless,
but you have dependencies between different parts of the route.
And maybe here comes the real reason I wanted to talk about the pipeline was that this abstraction done
this way gives you kind of like an algebra that you can use to combine pipelines,
to have prebuilt pipelines,
plus them together,
or maybe just join them together,
or remove things from them,
or maybe saying,
because it's a tree,
like a,
ends up being dark,
directed acyclic graph.
means like,
I want to get this sub pipeline that produces that output.
And then it will remove everything from you.
Okay.
So maybe you're like saying,
I only care about the output at the,
say,
fifth function,
this round timestamps thing,
and it could strip off a whole bunch of the other pieces.
Because it's like,
well,
all this other stuff is not involved in this part of the chain of the pipeline,
reversing the acyclic graph.
Yeah,
exactly.
And you don't need to do anything.
You just need to say pipeline two,
and then specify.
So we have a bunch of methods that you can use.
And,
uh,
unfortunately they're underutilized.
Like people don't really use them.
And then when we ask like,
Oh,
how can I do that?
And it's like,
there is one method call and people are like,
Oh,
that's so cool.
Maybe we need to improve our documentation.
And this one.
Yeah.
Maybe you should go on a podcast and tell people about it.
Yeah.
I think that's why I want to use the opportunity.
Yeah.
Absolutely.
You should.
Do you want to elaborate on some of these larger pipelines that you'll have going?
This actually speaks to a lot to the collaborative way that you can work once you're using the
Kedra pipelines,
because now your team sessions can easily become something like,
okay,
I know I need to work on like these three key functions because we know this is what we
want this pipeline to do.
And then you split out the work and work accordingly to produce those specific nodes and functions.
Also,
one of the things that I'd like to call out about the pipeline abstraction is that you definitely
do get Kedra Viz for free on top of it.
It's a pipeline visualization tool.
It's really cool because it allows you to give like kind of like a bird's eye view of
what's going on in the pipeline.
So you can actually understand like how different things are connected.
some of the ways our users have used it, but ways that we didn't imagine it was originally created for being able to talk to non-technical users or stakeholders about the way that the code base was structured instead of diving into code and showing them,
hey,
here's how the code works,
because they'll be like,
I don't know what's going on here.
But we've also found our users will do things like debugging with Kedra Viz to find out,
oh,
something doesn't appear right in my pipeline and then figure out what's going on there.
And in some ways,
we've actually extended some of that functionality.
So you'll see that there's now like a code viewer for you to interact with your code.
And we have some,
I guess,
maybe exciting things planned down the line when we're talking about the roadmap.
We'll be able to allude to some of the work that we're doing with experiment tracking,
which will extend Kedra Viz a bit further.
So nice.
Yeah.
You can definitely tell if you've got like a dependency mismatch and the order is wrong or something you could see,
oh,
this one is supposed to be after that one.
And it's really nice.
The visualizers.
It's nice.
You've kind of got this like map thing you can cruise around on.
And for people who are listening,
I'll definitely put this in the show notes so you can open it up.
and explore it.
There's a pretty elaborate pipeline here to explore.
Does this do anything runtime or is it just for visualizing the static structure?
It's actually just for visualizing the static structure.
We often find,
we've tried to skirt away from what we call the orchestrator UI interface because it takes us a bit too much.
I mentioned into that realm of like where we would prefer the orchestrators to play a part.
So for now it's just static view of what's going on in your code base.
Yeah.
No,
this is great.
I feel like a lot of projects would benefit from this kind of stuff.
not just data science things,
right?
Like I'd like this kind of view of my code for other things as well.
We have found people using,
KedroViz is also available as a React app and people use it in,
without Kedro.
So we'll find that they will build,
one of the most common use cases we've seen built on top of KedroViz is data lineage,
but specifically column level lineage that people will want to visualize.
So they end up using the React app for that.
I also have a friend who was playing a game.
He's actually one of the former maintainers on Kedro,
KedroViz and Kedro,
where he was playing a game where he needed to work on how to build,
I don't know what this game is called.
How to build.
It was Factorio.
Factorio.
You basically look at like how to,
how to build up your factory,
I think,
or something like that and use the different elements in the factory.
and he used KedroViz to visualize what he should be doing in his factory.
So yeah,
it's different ways.
Oh, that's funny.
I guess you can visualize lots of things with it.
How neat.
Yeah.
All right.
The next main feature here is deployment.
One comment I had on the,
on the pipeline was,
so,
you know,
you get a task to do on your sprint.
You sit down to work for the day.
And if you're not in this Kedro type of,
or this framework mode,
a lot of times it's like,
okay,
open the notebook or open the script.
And I've got to run to a certain point to start my work.
Cause I've got to have that data in memory or I,
I,
that's my option.
Or I'm manually saving things along the way.
Both have their downsides.
But so a lot of times it's like,
okay,
I'm going to run the notebook and then I'm going to go grab coffee.
And maybe when it's,
when I get back,
I can start my work.
So Kedro is saving each one of these points in the background along the way.
So when I get a task and it's like,
Hey,
you've got to put a note in between these two,
I can start right away.
Cause the data is already sitting there.
Oh,
that's cool.
I can also use the pipeline dag object.
like Ivan mentioned to just run that section of pipeline I'm working on as I'm working.
Interesting.
It's a little bit like just rerun the failing tests or just this one test or something like
that in the unit testing world.
Like instead of trying to rerun the entire test suite for every little change.
Yeah.
That's a cool thing.
All right.
You did talk about the deployment stuff before.
So maybe you want to touch on some of the deployment stuff.
I guess it will just be a quick mention.
So what we do support is two deployment plugins right now.
The first one is Kedra Docker,
which packages your Kedra project in a Docker container.
And the second one is Kedra Airflow,
which was built with the Airflow astronomer team,
which will take your Kedra pipeline and convert it into an Airflow DAG so that you can run it on Airflow.
But we also do support in our documentation,
like a few guides on how to deploy Kedra on Prefect,
on Kubeflow,
on AWS Batch,
AWS SageMaker,
and AWS Databricks as well.
One of them.
I always feel like with AWS and Azure,
there's just,
no matter how much I studied,
there's like three more things that are similar to what are there,
but they're different.
So like I know Batch,
but not the one you named after that.
Yeah.
That's definitely the case.
I believe it's AWS Databricks.
But you can kind of use the same methodology if you're working with Azure Databricks as well to deploy things there.
Ivan alluded to the fact that we do really pride on flexible deployment
because we don't know what is your internal infrastructure like
and therefore should be able to support the most generalizable case to do that.
So you can definitely check out those guides.
I know if there are guides missing,
just raise GitHub issues and we'll look at it.
As well,
we add a growing tally of mentions of things that we haven't heard people necessarily using with Kedra.
Yeah,
it's worth checking out.
Yeah.
It's open source.
If people want to add new deployment stories,
they can go and PRs are accepted.
Is that true?
Yeah.
Write up a guide and we'll take it.
We have a great sense of contributing guide that's available on our documentation too.
That shows you how to make,
I mean,
PRs across like whether it's features or minor tech improvements or bug fixes,
as well as documentation too,
because we like to write our docs.
Yeah,
that's important.
And coming into October,
it's October.
So people can come in and I think we will be really,
really grateful for adding more deployment because no matter how many you have,
you always run out of,
or maybe differently,
like no matter how many you have,
you always don't have everything.
And there is always someone would come and like,
by the way,
how do you deploy it on this AWS,
whatever,
the new thing that they have?
It's like,
how do I know?
It's like,
this is the first time I hear about it.
So there is always room for more.
And this is the thing that we would really,
really love help with.
So if you want to find something to contribute to for this October,
maybe that could be Kedra.
Yeah,
that'd be awesome.
Yeah.
I periodically will get in October contributions to like,
for example,
my course projects,
the GitHub repos for them.
And it would be like slight changing in the wording.
And if so,
like if it says the Kedra documentation includes three examples to help you,
you get started,
they might say to help you get started.
The documentation contains three examples.
There's a PR.
So I,
it counts.
I'm like,
so I just got to go through and close them.
So please people listening,
just a minor useful contribution,
but yeah,
it would be great to work on this.
Right.
And I feel like these types of pipelines are very accessible because they,
they narrow the focus so much,
right.
When you get down to like certain tasks and certain things,
you don't have to understand the whole project.
Just how do you do this other tasks slightly differently?
Yeah,
absolutely.
And I'm pretty sure that talking about contributors,
like if it's just change of words,
we might not have t-shirt for you.
If you're adding a guide,
we would definitely send out a t-shirt.
Oh,
nice.
Awesome.
T-shirts are included,
not just a passing.
Uber fest.
Okay.
So one of the things I find is a little tricky,
uh,
is always talking through,
or like thinking through an example of these kinds of things.
They're very neat,
but they also sometimes feel pretty abstract.
So even you would,
maybe want to talk us through,
uh,
just this like hello world example.
I know it's hard to talk about code on audio.
So not,
not exactly,
but just give us a sense of what it means to write one of these pipelines.
Yeah.
Sure.
Starting from the first one is,
uh,
I think in the hello world example,
we have,
we show like what a node is and,
and it's not very different than a function.
It's just a function actually.
And your function,
we accept two types of nodes,
actually three types of nodes,
nodes that have only inputs,
nodes that have only outputs,
or nodes that have both inputs and outputs.
So we don't accept functions that don't have neither inputs nor outputs.
So for obvious reasons,
because that doesn't do much.
And,
uh,
you can start with your own function.
Let's say you can call it return greeting,
which will just return hello.
So,
uh,
just let me elaborate on that for a second.
So what you have is a Python function that takes no parameters and returns a string.
But the thing that's notable about this is it doesn't have a decorator or some other special thing about it.
It's literally just a bare Python function that has nothing to do with case.
With Kidro per se.
Yeah,
absolutely.
So the reason why we did it this way was to allow all kinds of people just to create functions.
Like if you don't know decorators and these kinds of things,
you don't need to know that.
And then the second one is you might actually use functions from libraries that were not at all designed to be part of our framework.
You know,
if you're importing a function,
you cannot add a decorator on that one.
Well,
there is ways obviously in Python always,
but it's not,
you know,
very intuitive.
So we just work with pure functions.
how that gets turned into a node is actually more curious here.
And then we have a,
like it happens to a helper function we have,
which is called node conveniently.
And then you provide your function and you provide your inputs and outputs strings.
So these are the three things you can add.
So for example,
for this return greeting function,
your inputs would be none.
So,
because you don't have any inputs and your outputs could be a string,
which says my salutation.
That's in our,
how we've done in the hello world example.
So this will create a node in Kedro sense,
which you can embed later in a pipeline.
Nice.
And then here,
the output has a static.
Is that like the name of the output?
So you can use it in the pipeline?
Yeah.
Not the value,
but like the name.
So you can refer to it later on,
right?
Yeah,
exactly.
So you can think of them as variables in a way as a variable,
the variable,
like you can define where to store that valuable through the data catalog later.
Yeah.
Very nice.
So it seems super easy.
You have also a more elaborate example.
It says a space flight tutorial.
Yeah.
So people want to,
what is this?
And we don't have to talk to it.
Just if people want to go and play with it,
what is this one?
I really want the editor to introduce it because initially when we were thinking of an example,
I think she came up with the idea to make it more of a space flight.
And we actually,
it was quite funny that this led to something more interesting that the editor can share about.
Yeah.
Nice.
I think it was actually Dimitri that did this.
he was a former maintainer on the Kendra project.
But the scenario for this tutorial is that it's the year 2160.
You're somehow a data scientist predicting the price of space flights to the moon and back.
And you have access to three data sources,
information about companies that are flying people to the moon,
reviews on their shuttles that they have,
and then also the customer reviews that they've given while working with those companies.
And the whole thing is you just want to predict the price of a space flight.
So if you go through the tutorial,
you'll get acquainted with all the way from beginner functionality,
like install Kedro,
you know,
set up my project template,
all the way to kind of intermediate,
just before intermediate functionality in Kedro.
So you get up to speed in about like an hour,
an hour and a half in total,
as you go through the full tutorial.
And it will teach you all the basics of like,
how do I use the project template?
How do I use the data catalog?
How do I construct my pipeline?
How do I visualize my pipeline?
And how do I package my project as well?
So it's really useful for getting up to speed on that.
But we've had a really great time with the space flights project,
because we found out that NASA,
a team at NASA was using Kedro.
So it was almost like a dream.
Oh, nice.
When we discovered,
when we discovered that,
because it was like we went full circle and went to the moon with them.
They're actually doing space flights.
Amazing.
Yeah.
I'm pretty sure they chose this only because of our tutorial.
We were thinking Luigi,
but then we saw this tutorial and we knew this was the one.
Now, I do love these imaginative examples and tutorials
rather than something really boring.
Like, oh, let's build a to-do list.
And here's how we're going to do it.
Like, okay.
No, this sounds really fun.
So if people want to get a sense for what it's like to work with Kedro,
you recommend this as the tutorial to work through to get started?
Definitely recommend this.
And then there are a few online resources if you want to use them.
We have a blogger.
I mean, he's been inactive for a while,
but he still has really good YouTube tutorials.
Search for Data Engineer 1 and look for his walkthrough of the tutorial there.
It's also very handy for getting up to speed if you want a video kind of like workflow
as you go through the tutorial.
But we are going to be repiloting some live stream workshops of us working through the tutorial
ourselves later on in the year.
So definitely do look out for that on, I think, probably the Quantum Black YouTube will have
them.
And then also, oh, yeah, you can actually see.
I'm here, opened up.
First, I got to get through the ad for people to see.
I'm not logged in over here.
But yeah, there we go.
That's Data Engineer 1 in action.
And then I definitely recommend either joining in on those live streams as we host them.
Nice.
Or live the follow-up YouTube videos as we do them.
Yeah, cool.
I'll link to some of the YouTube videos for people to go check out there.
Very nice.
So we're getting pretty short on time.
Maybe one thing we could just do to wrap this up is maybe, I know you talked about some of
the cool libraries and stuff you used to build this.
Maybe you could just talk a little bit briefly about the internals and some of the fun things
you used there.
Sure.
So probably good libraries that were mentioning.
And maybe I will not use the time to too much about Kedrus internals, but like just to
have a shout out for nice libraries that we found out.
Yeah.
One thing that Waylon already mentioned was FSPEC.
I think that was amazing.
And we really found it super useful.
I think it is in the Anaconda ecosystem developed by some of the people there.
And the good news is that actually it's also becoming part of Pandas.
So whenever you're doing load CSV in the newest version of Pandas, they use FSPEC as well.
Oh yeah.
And now it says it's also in Dask, Pandas, even DVC and many other things.
This has been really, really useful because it simplified a lot of our code about the datasets.
We didn't have to, previously we had the dataset for S3.
We had a dataset for GCP and GCS and Azure Blob Store and all of that.
I don't know.
It's super annoying because they do exactly the same thing.
You do it like many times, just changing endpoints and things like that.
It was super frustrating to maintain it.
And when we have many of those datasets, it was super frustrating.
And when this came out, it simplified basically, maybe reduced our code base for datasets three times or something like that.
Wow.
Yeah.
Because they do that abstraction for you.
Yeah.
You just pass it along, right?
Yeah.
So if someone wants to treat a remote database as kind of like a local file, I think AppSPEC is really useful too.
Cool.
Let's see.
Another one that you mentioned was Dynacomp.
Yeah.
That's a quite nice one.
We started using it recently.
What we wanted to do in Kedro, because we are a framework, and there is some framework code that needs to call user code.
And that's a bit challenging because you don't know what the package name of the user, because the user will create their own code.
They will choose a package name, and you don't know what to import from.
So we came up with a pattern that was actually applied by Django, which you kind of configure projects by their package name, and then you load some of the settings.
So if people know Django, they know that they have an extensive way of doing settings in order to configure different things in Django.
How Dynacomp helped us with that is because it was a very extensive, like very clean abstraction to do lazy loading of settings.
And why did we need lazy loading of settings?
And for example, you might have multiple pipelines in Kedro.
One of them would not be completed.
There could be some errors in it.
But you still want to run the other pipeline.
And if you eagerly load all of that, then your code will fail for no reason.
Right, right.
Even if you weren't actually going to end up running that part.
Yeah, exactly.
It's almost like a compiled language versus a dynamic language.
Yeah, and here Python shines, right?
Because you can have things like Dynacomp, where you don't need to compile that path.
So it helped us a lot with making those settings loaded lazily, because there were different things.
You can add validators to validate settings and so on.
It's fairly extensive.
I recommend people to read their documentation.
You can use it for many things.
So yeah, it's a nice package we stumbled on.
Yeah, very neat.
Those are great recommendations.
So with just a little bit of time left, let's wrap up our conversation with where things are going.
Yatunda, maybe want to give us a roadmap future view of what people who are maybe using Kedro now are like, what's coming?
So I guess maybe one of the next upcoming feature that you'll start to see being rolled out is experiment tracking in Kedro.
So what we're doing is Kedro is already, I think Waylon spoke to it, really aware of like being able to save your data sets.
And for us, our data catalog would apply to models as well.
So we already had some form of model versioning in Kedro.
But what we really needed to extend, and we already have a concept of parameters too, so inputs.
But what we really needed to do was think around how do we think about features and how do we think about metrics coming out of the pipeline as well.
And those are the two additions that we've made kind of as additional data sets in the Kedro framework too.
And then the last thing that we had to think around was like, how do we collect all of these things as one unit or one experiment?
That concept is actually very, it's actually been implemented on the framework side.
So you can really start to interact with the, you know, experiment tracking functionality there.
But a lot of the massive changes are going to be done on the front end, where you'll be able to, you know, look at the list of experiments that you've run, compare them as well.
And then we'll be building up like the functionality as we see fit, including probably MLflow model registry and model serving integration as well.
And that's probably going to be done through our data catalog as well.
Oh, that's cool. Is that if I go to the trouble to train up a model and it takes a day, I can store that and other people can just pull it down and use it without spending another day?
Exactly. That's the large thinking around it.
So yeah, you can definitely look forward to that.
There's some open issues on the, our GitHub repository around configuration.
So I do suggest if users have, you know, interacted with Kedro and you've had issues with scaling configuration, please do check it out and give us comment there.
Because that will decide whether or not, like when we pick those, those issues up based on like user responses there.
So that's what I think you can look forward to.
Oh, fantastic. All right.
Even I think we're going to take your two libraries you mentioned as the notable PyPI projects, just for the sake of time, since we're kind of over.
I'll just do one final question for everyone out there.
And that's if you're going to write some Python code, what editor do you use?
Even you want to go first?
IntelliJ.
I come from Java and Scala world.
So I stick with IntelliJ.
So basically the Python support in like full-on IntelliJ, right?
Yeah.
And not PyCharm, but IntelliJ.
Yep.
Go ahead.
Ivan says like, no PyCharm, I'm full PyCharm.
Same here.
There's arguments on the team about this.
Oh, is there?
This is a point of contention.
I see.
That's funny because they're so similar, right?
It's not like VS Code versus PyCharm.
Oh, Aylan, how about you?
I'm an avid NeoVim user.
You know, part of my workflow as being a lead data scientist is I bounce between probably
like a dozen projects a day between like actual running pipelines, or maybe it's like a couple
of our internal libraries that help like those things run.
And it's really nice to have something lightweight that can run with pretty low resources.
Also, having it running in Tmux makes it easy to like a few keystrokes.
They can go into a specific project.
The editors, they all tend to look the same.
And you have a bunch of projects looking the same.
It's very easy to edit the wrong one.
Yeah.
Cool.
All right.
A good recommendation.
All right.
Well, thank you all for being here.
Maybe final call to action.
People want to get started with Kedro.
Bring it into the organization.
Try it out.
What do you all say?
Well, you know how to get started.
Get into the Spaceflight tutorial and then just shout if you have any issues.
We're up on Discord.
And we also do have a GitHub discussions page as well.
So you can just flag.
We help users across the different levels of where they find themselves.
So definitely do that.
Yeah.
And I guess Quantum Black does consulting for Kedro.
So if people have these projects and they're like, I'm not sure we can handle this ourselves,
they could probably hire you all, right?
We've never quite had that level of interaction.
It's not that a Quantum Black data science and data engineering team will go out and use Kedro
as part of a larger engagement on like, how do we make a business problem?
So you can definitely learn Kedro through that way.
But you're in the open source community as we move in the open source space.
It would definitely be through the channels that we have available.
Cool.
One thing to mention is like, if people want to engage with Quantum Black because they know
about Kedro, please mention that.
I mean, like, we found it because of Kedro, you know, the Kedro team.
So that, you know, we get the Keds.
Yeah.
Awesome.
Yeah, I bring that up because there's different ways to support open source, right?
I mean, there's the MongoDB model where they sell MongoDB as a service and Atlas and all
that.
There's, you know, like Tidelift.
There's GitHub support.
But here's like yet another way in which this project is being grown and being supported
because it's, you know, supporting you all doing your work.
So, yeah.
So, I mean, if that's the case, then I'll definitely say we do really want to be able to help a
lot of people in the industry as well, because we know that it's needed.
And we obviously recognize that as a framework, especially in the data science space, we are
a bit of a first mover.
So we suffer a lot of like first mover pains where people are like, why on earth do I need
a framework?
I don't need a framework.
So if you help us with breaking through those barriers, like please go for it and be an
advocate.
And I guess in this sense, be a Kedroid.
Right on.
All right.
Yatunda, Waylon, even thank you all for being here.
It's been great to learn about Kedro and great to chat with you.
It's been awesome.
Thank you so much.
Thank you.
Bye.
Thanks, Michael.
Bye.
This has been another episode of Talk Python to Me.
Our guests on this episode have been Yatunda Dada, Waylon Walker, and even Donov.
And it's been brought to you by Tab9 and us over at Talk Python Training.
And the transcripts are brought to you by Assembly AI.
Supercharge your editors.
Auto-complete with Tab9.
The editor add-in that uses AI to learn your coding styles and preferences and make you even
more effective.
Visit talkpython.fm/Tab9 to get started.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Thank you.