When you think data exploration using Python, Jupyter Notebooks likely come to mind.
They are excellent for those of us who gravitate towards Python.
But what about your everyday power user?
Think of that person who is really good at Excel but has never written a line of code.
They can still harness the power of modern Python using a cool application called Superset.
This open-source Python-based web app is all about connecting to live data
and creating charts and dashboards based on it using only UI tools.
It's super popular too, with almost 50,000 GitHub stars.
Its creator, Max Bushman, is here to introduce it to us all.
This is Talk Python to Me, episode 382, recorded September 19th, 2022.
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.
Did you know one of the best ways to support the show is by taking one or more of our courses?
In fact, we have one of the largest libraries of Python courses out there with over 240 hours of videos.
Before we get to the conversation, I want to quickly let you know that we just released three new ones.
Django Getting Started, Getting Started with pytest, and Python Data Visualization.
All three are excellent courses, and their landing pages each have a video introducing the course.
Visit talkpython.fm and click on Courses in the nav bar to learn more.
Thank you for making Talk Python training part of your career journey.
Now on to the show.
Max, welcome to Talk Python to Me.
Well, thank you.
Exciting to be here.
Love to talk about Apache Superset, so hit me up.
Yeah, it's quite the thing that you've created, and it looks like it's really going strong.
So we're going to talk about tools for data exploration in general, and then we'll dive in and focus on Superset, which is what you've created.
So I'm really excited to do that.
Excited to do it, too.
I've been kind of baiting and kind of swimming in this old world of data, data orchestration, exploration, visualization for the past 20 years or so.
So that's been really my focus, so I should have a lot to say about everything related to this space.
Yeah, fantastic.
And you've got a lot of experience at many of the big tech companies that people would think of as having lots of interesting data to look at.
So we can dive into that just a bit at the beginning here.
But before we get to any of those things, let me kick it off with a beginning question.
How did you get into programming and Python and all these things?
Oh, goodness.
Yes, I did a decline of an associate degree back around like in the late 90s.
So that kind of, you know, says about how long I've been doing this.
But I never finished it, too.
So I never finished and got my actual diploma for it, too.
So I got into an internship to join a company called Ubisoft.
So it's a video game company.
It's one of the major video game companies out there.
And I went on to my first internship and never looked back and never finished a program.
So that's where my career started.
That's awesome.
This program was like very, it's called a Technic Online Filmatics.
I'm from Quebec City originally.
So I grew up speaking French and I was a program in French.
And it's a technical program.
The goal of the program was to send, you know, technicians, as they call them, people that are very technical, really focused.
And then give them the skills that they need to be effective joining companies.
So some programming, some data modeling, a little bit of SQL.
And then really, like, the skills that you need to get started and start coding.
Not necessarily thinking about, like, computer science and, like, data structures.
Like, much more, like, what do you need to get started?
Let me interrupt you for just a second there.
And we can maybe talk just a bit about this.
I feel like a lot of people looking in from the outside feel like, oh, I need a computer science degree in order to do X, Y, or Z.
Whatever it is, you know, create APIs, create a business, do data science or whatever.
And so much of the focus of CS degree seems to be on algorithms, on operating systems.
And while those are really good to know, they're not necessarily the skills you sit down and go, let me remember my algorithms things.
Like, you just call a function on a data structure.
Or let me remember my operating system stuff.
Like, you just run the code.
I mean, it's helpful to have that.
But I don't feel like it's that necessary.
I don't want people out there listening to think, oh, I've got to go get a CS degree or I'm not going to do anything, right?
Yeah, I think, you know, the boot camp, I've been told, like, flip that upside down to say, like, oh, no, all you need is the technical skills to get started to, I don't know, build an app, you know?
And then you don't need those fundamentals or maybe the premise that you need them later.
I think there needs to be some balance there, you know?
So the CS approach, like, let's start with the foundation and how we got here.
And then, you know, the rest should follow.
I don't think that's right.
So to me, you don't really have that curiosity about how you got there until you've been a practitioner.
So to me, I'm like, hey, teach people the skills they need to be successful and useful to employers.
It seems like the way that university in general or education should be oriented towards.
Let's teach people the skills they need to be to contribute effectively to the market.
And then I think maybe the CS constructs is something you would learn, that wisdom you would build, you know, as you learn.
Some of you would pick it up and some of you are like, I really need to know.
I've been doing this for a year now.
I need to know how this thing works.
And you'll dive into it, right?
But when you're motivated and you're kind of, you have that experience already, yeah.
Yes, it's like when you have to solve the problem, certain problems.
And then maybe at that point, I don't know, if you're writing a bunch of SQL and you're building a lot of data structure, maybe you need to understand like data modeling construct.
And that's a good time to go and understand the history of the different approaches to data modeling.
But maybe you don't start from the theory, right?
Yeah.
But yeah, so like going back to your question, so I, so then I joined a, so I was a web developer kind of building internal apps for like a year.
And then very quickly I got into data and got into using, building data warehouse at Ubisoft and then using the business intelligence kind of tool set toolkit to build all sorts of ports, dashboard kind of self-service things.
So people could consume data.
So very quickly got into that.
And it's a little bit later that I learned, I started doing more scripting.
So when I joined Yahoo in 2007, I believe that was like the birth of Hadoop and Yahoo had some, some pearl, you know, so I learned a script a little bit and kind of interpreted languages more.
And then by the time I think I started, I started building more, more, more website for personal projects.
So learn a bunch of Python there.
I did a lot with Django.
And by the time I, by the time I joined Facebook in 2012, I knew Python very well.
And then that became kind of my, my main kind of my main language, you know, and that's really, you know, what we use internally for a lot of things at Facebook.
And that just became like more and more of the established kind of language for everything data related right around that time.
What a cool set of experience.
You know, you were at, was it Lyft, Airbnb?
Yeah.
Facebook.
Yeah.
Facebook.
Yeah.
A lot, a lot of.
And Ubisoft.
Yeah.
So Ubisoft is interesting.
They're a Canadian company, right?
They are a French company.
So their headquarters is in Montreux, like very, like next to Paris, or I think they were actually like they're from Bretagne, so Brittany somewhere.
And.
Okay.
They're a French company.
They have a huge studio in Montreal, though.
There's like amazing tax breaks in Quebec and Canada.
And they decided to build like one of the biggest, if not the biggest video game studio in the world in Montreal.
So that's where I started my career.
Yeah.
Well, the reason I'm bringing it up is I want to ask you about what it's like working at a game company versus a more traditional.
I don't know if you call Yahoo traditional, but like standard.
You know, a lot of people dream of being at these game companies.
And that's even maybe why they got into programming.
And I don't know.
Tell us what your experience was like there.
Yeah.
So it's a dated experience, right?
I don't know what it is.
Like I left Ubisoft in 2007.
So it's like a pretty dated.
It's 15 years ago.
I can say about like what it was like at the time.
It's a mix of like super fun.
It was like super young, a bit bro-y too.
And a lot of ways in a very masculine environment.
Also, like, you know, some of it is because it's, you know, 15, 15 to 20 years ago.
I think it was a slightly different world.
And a lot of things that were maybe dubious back then are definitely not okay anymore.
I mean, I think there's that culture.
People talk about, I think Electronic Arts has been famous for that.
And a lot of the big video game companies is having like these work environments that were
really like, you know, dubious in some ways.
But I think Ubisoft was a great place to be, I think, at the time.
And I think like maybe one of the better ones kind of bringing it back to where it should be
and ahead of its time, perhaps.
But my experience at Ubisoft was so interesting because it's difficult for me to talk about
what is Ubisoft because I work at three different studios, Montreal, Paris.
I was in Montreal for about a year until I was in Ubisoft Paris for about three years.
And then Ubisoft San Francisco for another three years.
So the three different offices were vastly different.
And I think, you know, the things that kind of plagued the video game business are like long hours,
kind of low pay, I think that just like grinding people out sort of thing.
Yeah.
Kind of like there's never enough, a lot of crunch time all the time.
And then kind of a great place maybe to start your career.
But then as people mature, they tend to go other.
So at least I think it has changed so much.
The whole world culture has changed a lot.
Yeah.
As you have relationships and families and you want to see them, things like that.
Yeah.
That might evolve.
Yeah.
Seriously.
You're going to age out of working out all the time or just by necessity too.
Yeah, exactly.
Let's kick off our conversation focusing on data exploration, I think.
So when I think about data exploration, not from a developer or data science, but in like
the super broad sense, I don't know what comes to mind for you, but Excel, I feel like most
people are like, I've got some data.
I need to maybe think about it a little bit more analytically than just a bunch of numbers.
Let me throw it in Excel and see what I can do with it.
Yeah.
I think Excel is like a super open.
If you think about like Excel as a playground or as a framework, you know, it's super open
ended.
You can do so much in there and there's not a lot of constraints, right?
So the constraint that exists in an Excel file, the ones that you make for yourself.
And then maybe one constraint is like, it used to be like, you know, I forgot what it was,
but it's like, you know, 65,000 rows, you know, for a long time.
And I think now there's no such limits anymore, but there's still like a limit of how much your
laptop is going to be able to, you know, in terms of the size of a pivot table.
And the past companies where I was at, there's no way you could bring the dimensionality
and kind of the raw data that you need in Excel.
So you need to kind of prepare and extract of the stuff you're going to play with.
Yeah.
First, you got to be in Excel.
And then there's like things that, you know, BI historically has not been really good at
is a what if analysis, creating different scenarios, doing forecasting.
So I think like that is an area where our spreadsheet dominate will keep dominating, right?
If you want to tie certain things to variables and change the numbers and see how other like,
you know, charts and models are.
So modeling kind of is a really good case, I think, for Excel.
Then, you know, the downside is like, oh, how do you collaborate on these things?
And like the version is kind of a mess where you end up with like another file, SharePoint.
Even the files are binary, so you can't, you can't diff them or anything easily, right?
Oh yeah.
They're not in source control.
And then you don't know, like there's no introspection as to like how things got there.
There are a mix of like data that are from a source and then kind of made up stuff sometimes.
Like, I'm going to tweak this.
I'm going to change that.
So you don't know what is the list of all the changes that were applied to the source data.
Yeah.
So I don't know.
I think it's a good tool, but it's definitely incomplete, right?
It's part of what the impact will always be, you know?
I don't bring it up as a recommendation.
I bring it up as I feel like a lot of people are starting here.
And so like, how can, how can we look around and see maybe what is a better option out there,
you know?
Yeah.
And it's, I think if you've used Excel a lot in your organization or personally, I think
people discover kind of hit their head on the limitations and the problems that come with
such an open framework.
This portion of Talk Python To Me is brought to you by Sentry.
You know, Sentry as a longtime sponsor of this podcast.
They offer great error monitoring software that I've told you about many times.
It's even software that we use on our own web apps.
But this time I want to tell you about a fun conference they have coming up.
Sentry is hosting DEX, Sort the Madness.
The conference for every developer to join as we investigate the movement and trends for a
better and more reliable developer experience.
What is this madness, you ask?
It's the never-ending need to deploy stable code quickly.
Come to DEX to engage with developers who will share their epic fails and their glorious saves.
Sentry can't fix the madness, but they can start sorting through it with you.
Register today to join in San Francisco or attend virtually on September 28th at talkpython.fm
slash DEX.
That's talkpython.fm/DEX.
The link is in your show notes.
Thank you to Sentry for supporting Talk Python to me.
Out in the audience, Ollie says, my local data extraction people default to Excel and they
seem limited by the number of sheets available in a workbook.
Yeah.
Well, I guess now that it's not the number of lines in a file, I guess the number of sheets.
That's right.
So, you know, sort of stepping up a level from this, I feel like maybe heading down a more
structured way.
Like, one of the problems with Excel is how do I talk to databases and APIs?
Like, how do I bring in other more live data is really, really limited.
I know there's like BI stuff, but not really.
Sort of the next step up.
What do you think?
Is that, is that Jupyter or like, where's the next level here?
I don't know.
Of course.
We're talking about consumption now in some ways, but I feel like in a lot of ways we
should be talking about data engineering too.
So where is your data, right?
Is the first question.
So first your data is not, or maybe some data lives in Excel, but that's not where your data
lives nowadays in the SaaS application you use, right?
So the modern, like just even any startup or company uses hundreds of SaaS applications.
Yeah.
CRMs, applicant tracking systems, you know, GitHub and just a million different data sources.
And it feels like one of the first thing you need to do is to bring that data together,
right?
Like in a central place or into some sort of like inside, you know, either data marts
or data warehouse.
I think like an early construct that you need as an organization because data is most useful
when it's put alongside the other data you have in your organization.
It does make sense to hoard all this data and bring it all to a central place.
If you want to do consumption, otherwise consumption is going to be kind of a stitching story, right?
So let's say you're in Excel or you're in a, you're in the local database or whatever,
whatever it might be.
The first thing you have to do is bring the things that are related in one place.
So you can do that visualization consumption analysis, right?
How do you join on a thing that's partly in an API and partly an air table or something?
Right.
Even if you, let's say we take a notebook, so super open-ended, right?
What is a notebook?
It's just like, you know, it's a script with REPL and, you know, where you can run, you
know, chunks of the script sequentially and you have a persistent kernel or interpreter
kind of supporting what you're doing at any point in time.
But the first thing, if you don't have a data warehouse or your data all in one place, you're
going to try to do some data engineering is probably the first thing you're going to do
within your notebook is to say, how do I get the data that I need?
The source or sources that are interesting to me and the notebook, you know, will enable
you for sure to do this, but then is it, you know, can other people build on top of the
work that you did in a notebook?
Probably not or not as easily as you'd want them to.
So I think the data warehousing kind of approach of saying like, hey, let's bring data that we
need in our organization to a central place and try to stitch it together there so it can
then best be used for consumption.
And analysis is still a very important step in the process.
Sure. I totally agree. And, you know, Jupyter gets Jupyter and JupyterLab gets a lot of the
mindshare, but there are many, many choices. I interviewed Sam Lau and he did a research project
where they categorized over 60 different notebook environments where Jupyter was one of them.
It's just, it's off the hook. So there's a lot of choices out there and so on, but let's focus on
superset.
I'd love to talk about outputs. It's like, why do we need to set 60 different notebooks? I feel like I
missed a step of like the evolution of notebooks. I'm very familiar with Jupyter,
deploy Jupyter hub at Airbnb a while ago, but then, you know, followed Hex a little bit.
That's one of the players in space. Also followed. So at Lyft, we kind of built our own little
notebook service, right? So we had a Kubernetes cluster. We kind of say like, I want this Docker
image base for my notebook. You'd pick like, I want the AI and now package, or I want, you know,
basically what's the base for your notebook. And then you could pick some hardware, like I need GPUs
or I need a big machine or small machine. And then we'd spin off these environments for people, but
try to understand like, what are the different, like, why is there 60 notebooks? And what's,
what are the different flavors? Or like, how do they all differentiate from each other? Is this dubious
question? It was crazy. I was kind of blown away by this. And if you look, they have a,
it seems like it always differs on some axis. Like, well, we want more collaboration like Google Docs,
or we want it to run into a different place, like PyIodip. We want that to run in the front end,
rather than, you know, with like some sort of Python in the browser. And like, there's just all these crazy
variations. So I think there's a lot, I just kind of only highlight that to point out, like,
it's not just Jupyter. There's like a ton of these things where, where Jupyter is the main
environment that kind of lives in a web browser where people go and explore data. And I feel like
Superset, it's a pretty modern, interesting player in that space of many choices.
Yeah. Happy to talk about Superset too, and trying to introduce it in the context of what we're talking
about before. Yeah. But think about Superset, right? Tell us about Superset.
So Superset is essentially very much like a data exploration, dashboarding, visualization tool that's very much
like catering to organization, right? So we, Superset solves like challenges or the problem space of data
consumption for entire teams. So we're not necessarily focused on people who know Python or people who are,
you know, data scientists or data analysts or data engineers, like we very much cater to the entire team.
And the idea there is to have a single place to explore data, visualize it, interact with it,
share, create dashboard. And then we have a SQL IDE on top of that too. I think like on the GitHub page,
I don't know here if we have good screenshots to, I think an image is worth a thousand word. And I know
not everyone is like looking at what we're looking at, but here we have the drag and drop kind of
explore. I think the, the screenshots a little bit dated there might be a little bit more recent on a
GitHub on the GitHub page too, where you can see like, and we have this drag and drop interface,
very similar to what people are familiar with in, in business intelligence, right? Like you, where you
have access to your data set and you drag and drop your metrics and dimensions and pick your visualization
type, get to the exact chart that you want. And you can assemble these charts into interactive dashboards
with like, you know, dynamic filtering on the dashboard and expose that to, to, to business users,
right? So they can explore on their own, they can create their own dashboard. They can answer their
own questions. Yeah. This sort of thing.
It lives in a really, really interesting space. And that's why I brought up Excel as well as because
Excel is not meant for programmers, but it's meant for people who are trying to do serious stuff with
it. They kind of, well, maybe the right equals and they'll find a formula they can put in there or,
you know, they'll do like a V lookup or they'll, they're kind of trying to go more than just like,
I need a grid of stuff. And while Jupyter and those things are awesome, superset feels like it caters a
little bit more to like a power user type of person that has Python extension capabilities,
but you don't have to start as a Python developer to get into it. Is that right?
No, actually not. Right. Like, so the premise is like, you don't need to have any Python skills.
The skills that may help if you want to go deeper inside superset is, you know, knowing some SQL,
knowing SQL, it's not a requirement. So think about like, if you think about Tableau,
people familiar with Tableau or Looker, right? That's really the space that we're in. So it's,
platforming in a sense that, okay, you can access, you can, you access your database connection,
you interact with datasets, but then, you know, think about the experience of a consumer,
someone just consuming a dashboard. You just, you open a dashboard, it's a collection of chart,
maybe it's titled like financial forecast for, you know, 2023. And you really need that little
technical skills to, to use to, you need business knowledge mainly to consume a dashboard. These
dashboards are interactive. So that means you'll be able to apply a filter on a specific quarter,
a specific like customer type of market, right. And then, interact with the dashboard in that way.
But primarily like the dashboard interface caters to the, the bit like the business user or anyone that
is trying to understand.
I see almost like a more of a BI type of a user person rather than...
It is BI tool. Super set is a BI tool to be, to be there. It's a BI tool that maybe is modern in
many ways and assumes. So if you want to get the way you get deeper, say in the Explorer, and I don't
know if you can, if you can click on the upper left on the Explorer. So here for context, we're looking
at more of the drag and drop place, and super set where you pick metrics and dimension and
visualization type you want to look at. So it's your typical kind of tableau like interface. And here you
can essentially just drag and drop, but if you don't do no SQL, you're able to create your own metrics and
express them as SQL expressions, for instance.
Right.
Calculated metrics.
Exactly. You can have computed columns and aggregation and stuff like that. Right.
Exactly. Yeah. So you'll define metrics as aggregate, as SQL aggregatable expression. So sum of this
divided by the count, this thing of that, and it has to be a valid SQL expression. But yeah, so for people
who are a little bit more technical, maybe understand the data better and a little bit of knowledge of
SQL, they can, they can, they don't have to, but they can use SQL as part of a
that exploration experience. So you, for instance, if you pick a filter here, you'll be able to pick
a column, an operator, like customer ID in, and then go pick the customer IDs in a
GUI type setting. But you can also go to the little SQL editor and a filter pop over and then write a more
complex SQL expression if you want to. So we wanted to not necessarily bury SQL as we feel like more and
more people are learning SQL. It's becoming like the lingua franqua of data. We feel like there's going to be,
you know, a certain percentage of the workforce in the next decade that's going to become
more data literate. And that's in part by learning SQL and understanding, you know, understanding
data set, data structures, and what data sets in their particular organizations are and are made out of.
Right. And by using SQL, it means you can connect to different data sources and you can connect to live
data, right?
That's right.
You don't have to do some kind of export or whatever. You just connect to Postgres or you
connect to whatever and then go from there.
Exactly. Yeah. So the, you know, the way things work in superset. So you go and create your database
connection or connections to whatever, you know, SQL speaking databases you use as a data warehouse,
as a data store. Things that are really popular right now are, you know, the big cloud data warehouse,
Snowflake, BigQuery, but there's still a lot of Postgres and MySQL, even for analytical use cases,
right? And people, so you connect to that database and then you go and you have different ways to get
started. One is to go and start exploring the tables that exist already, tables or views,
or you have this SQL IDE that you're kind of pointing to now, so it's possible for you to go and,
you know, step down to that level that's more interacting at the SQL level. And here you can
also create data sets, right? And create what we call virtual data sets that are essentially views for
people are familiar with the database construct of a view. And that allows people to go and explore
that data set of virtual data set, assemble dashboard, create visualization, collaborate with others,
right? Share links on Slack and, you know, annotate, add comments, that kind of thing.
Yeah. I want to dive into the data sources more, but I want to make sure that we highlight this for
people listening who don't know about superset. Two things, and you've hinted pretty strongly at one
already. First of all, when I go to Excel, I don't see a fork me on GitHub. I mean, I'm looking,
I don't see anywhere on this page that it says fork me on GitHub. Over on Apache slash superset on GitHub.
Yeah, clearly right there you can. So this is one, it's open source and two, very popular. It's
almost got 50,000 stars and 10,000 forks. Like that's Django flask level of popularity for people,
keeping score, I guess. Yeah, that's right. Yeah. And depending on, you know, and stars are just like,
some sort of proxy for, for hype or interest. Yeah. Right. And fork or like, it's good proxy for how
many people have kind of, you know, wanted to play with a code, which is also a proxy for a different
kind of hype and interest. But yeah, it's up there, you know, probably in the top 50 to 100
source projects of all time in terms of like value delivered and just popular.
Yeah. Which is like way beyond what I expected, you know, in 2015 when I started abroad. Same with
Apache Airflows. I also started Apache Airflow. That's also like very, very, very popular and used
in like tens of thousands of organizations. I think it's similar. It speaks to like the, the scale and the,
and just like how like the problem space is super validated. Like everyone needs to visualize data,
explore data, create dashboard, you know, write SQL, see results, you know, visualize results.
Yeah.
So very popular, definitely the leading open source project in this space, you know, of,
call it business intelligence data consumption. And it's a very mature project, right? So it's
used by thousands of people at places like Airbnb, Microsoft, Tesla, people have forked the project or
use it super heavily internally. That in the wild section that you're pointing to, which is kind of
trying to list out the people who use the project is very limited kind of version, the tip of the
iceberg type thing of the people who self-reported using the product.
Yeah. So you have a link in the GitHub repo called in the wild, and it just lists out under these
different verticals, you'll find these companies using them, which is, you know, on one hand,
it doesn't matter if these other companies are using it or not. But then if you're trying to sell
it to your organization or just trying to decide if you can trust it, like, well, if you know,
you're in education and it works for brilliant.org and it works for you to me and the Wikimedia
Foundation, maybe it'll work for you. You know, like that's a, it's a bit of validation, right?
Yeah. And then, you know, especially looking at like, those are people that, you know, open
a pull request to add their name to this like hidden file on the repo. All right. It shows how like
two percent of the iceberg it is. But I think one thing I've been telling people on, in the context of
this podcast is it makes sense. It's like, if you want to contribute to open source, there's a lot of ways you can
contribute. And the obvious one is to, you know, use the software, open a pull request. But the less
obvious one is to let the world know, like the very, the most basic and the very minimum, maybe when you
use a, when your organization is getting significant value from an open source project, just to be public
about it. Let the world know, you know, if you work at Uber and you get tons of value from, I don't know,
Gatsby or like when, like whatever, let the world know that you do. And that's a vote of confidence.
And it speaks to the scale of the community and kind of to work for other others. It probably,
you know, the chances it's going to work for you are much greater.
Yeah. Another thing that's interesting about the GitHub repo source code, really, I guess,
is what I'm thinking of. Two things here. One is it's, it's super active, right? If you go in here
and you look around, like sometimes you'll see, you know, last change two years ago or whatever,
right. But oh yeah. Last change seven hours ago, a couple of days ago, two days ago, right?
There's a lot of, a lot of activity here, right? Yeah. It's, it's super intense in terms of like
how many people work on a project. There's like a contributors tab. You might be able to click on to
on the right there, click contributors. So 832 people have contributed today. And that's just looking at
code contributions. Here's possible to see the history of who's contributed. Something that's interesting
is like, we distributed on PyPI, but, and the project was largely Python code. It looks like we
have too much data and the GitHub UI is struggling to render. We're going to break GitHub. Sorry, GitHub.
Yeah. We're breaking out GitHub right now because we have too many contributions. Here you can kind of
see the scale contribution. You can also see how I've been selling into my CEO role and less in the
code. A bunch of people have contributed over time. But yeah, I was going to say we decided to
distribute on PyPI originally and, you know, was largely a Python project from the get go,
like more and more. I feel like at the code distribution, a lot of the code is in TypeScript,
JavaScript now because the nature of the project is so, such a front end project. And something that's
interesting about open source is we have seen less like application GUI type app, like up the stack
type projects really succeeding at scale. And superset is definitely one of those, like very much a
front end application type product that's open source and then succeeding at a massive scale too,
where typically in open source, we see libraries, we see backends and frameworks,
right. Like being really massively successful. But you know, that was part of the reason that I
really wanted to, I wanted to prove that superset that that superset and, and that, you know,
open source can succeed up the stack too. And we've been working very, very actively on that in this,
in this community. Yeah. It's a super good point because it's clearly open source has won on the
frameworks in the libraries level, but there's fewer examples of it creating beautiful user interface
experiences and types of applications. And yeah. And I pretty good theory on that too. Like,
why is it the case that we've seen this? Why do you think?
So I think like open source has been very much playground for engineers, right? Like the,
the tool set and, you know, GitHub and Git and source control on the pull requests and issues,
like all of these things have been historically the way that engineers build software. And it's
been a little bit hostile to PMs and designers, not hostile and like, oh, you know, actively hostile,
but just, it was not, not welcoming. Yeah. Or yeah. Not it's just built by engineers for engineers,
like GitHub and Git was built by engineers for engineers. And we never really thought of like,
how do we include product designers and product managers to the workflows there? And then the interest,
I think a lot of engineers have like this great image of open source and see it as an outlet for
their careers. And then they love the idea of working in the open that does not exist that drive of
working in the open, you know, with the designers. So we've been thinking about how do we create and
large our community and open up our community to very much welcome PMs and product designers as part of
this community. And it's been, I think we've made some headways. We should blog about how we did this
in the superset project, but we opened up and we created some processes where, where we also do design
review. We do, you know, product reviews that our PMs get together with other people in the community to,
to kind of design beyond, you know, technical solutions.
Yeah. There's a ton of visualizations here for people who haven't seen it yet. Just visit the
website and you'll see right away. There's a primarily a visual tool, the tool for visualizing
data, right?
Yeah. So it is like a GUI tool in a lot of ways. But, but I think what's interesting too,
it's a GUI tool first, right? So it's a BI tool in the sense that, you know,
a lot of what you do is point and click and drag and drop and, you know, hit a save button. But because
we're open source, we also have, we're pushing the APIs and SDKs very strongly too. So it's probably
the most platformy BI tool around because of our open source.
Oh yeah. That's cool.
Because we started from the ground up. So say the visualization is a plugin system,
so you can create your own visualizations and distribute them. The backend and Python is like,
you know, the coverage of the API is like a hundred percent, right? It's like all over. So everything you
can do in the GUI, you can do as code too.
Okay. Yeah. Right now the audience is asking, does it expose an API to your data?
You know, which is-
Yes. And it should be in the docs, right? So if you go to, in the docs that,
here somewhere in there, there should be, maybe it's API at the bottom there. I don't know how
well documented it is here. It should be, it looks like it's not rendering right on like 480 by 320 pixel.
Yeah.
Here we go. How's that?
Oh, there you go. So command minus to scale this, but yeah.
Exactly.
So very good API coverage and well-managed, you know, API behind the scenes.
Yeah. It looks like you even expose some directly, some of the open API Swagger type of documentation,
which you could maybe even auto-generate some stuff. Does it have like a library of a Python package that
talks to the API, anything along those lines? Or is it just HTTP?
I think it's a open API and then Swagger.
Yeah.
Right. I think I set up the first version of that a long time ago, but yes, it's a self-documenting
thing. So if you put the right decorators and the right doc strings and it's self-document.
I think we do Marshmallow too, and other things to do like schema definition of what can come in and
out. And that dictates, I think that's self-documenting too, in terms of like the input and expected
output schemas too.
Mm-hmm.
Sound very neat.
Yeah.
Or it could be like Python, Python three, like type annotations too. I think it gets picked up properly,
which is great. Beyond that, there's more like there's JavaScript stuff. There's a plugin. I think
if you were to Google superset plugin examples, you'll find all sorts of resources, maybe out of the-
There you go.
Oh, there's even a whole collection of them. Yeah. Look at that.
Yeah. So it's managed a different reef.
I didn't Google, I kagied it. I don't know what the word googling with kaggy is, but there you go.
Got it. Yeah. And then we have a good blog post on the preset blogs. If you go preset io/blog,
we have like how to get started and write your first superset plugin. That's a much more like
JavaScript. That's a hundred percent, you know, TypeScript, JavaScript, front end code to build plugins.
It has to be, right? Yeah.
You don't want to be in the backend trying to figure out how to, you know, lay things out or use
the Python library to do interactive visualization. It just doesn't work super well. So the plugin
framework is all, it's all front end code.
Yeah, makes sense.
Beyond that, there's more API than there's component libraries as part of superset. And there's other,
SDKs and component libraries.
Yeah. So the first thing I wanted to point out about the source code and the GitHub repo is just
the popularity and all the contributors and whatnot there. The other is that this, while not necessarily
made for Python people, the way that Jupyter would be made for BI users, but it is open source and in Python,
built on Flask and tools like that. Right. And you talk about the extensions on the backend and pieces
along there. So maybe just talk about for people that want to dig in from a Python side, what can they find?
Yeah, we could try to open the requirements folder. Because at this point, it's not even a requirements
at TXT file here.
You have a whole project for setting it up. Okay.
Our consider requirements.
Yeah.
Oh, you guys using pip-tools here? Nice.
I believe it's pip-tools and a pip compile, you know.
Yeah. I love working that way. That's my way these days. It's great.
Yeah. Because we need to pin the versions. And so we have to, for people to know with it,
you define an in file that's like your version ranges, and then you can kind of pick, compile your
version. And then that turns into like kind of frozen, like libraries, like specific numbers.
So it's, you know, you can have like everything pinned out. We use so much stuff here and we use
stuff that uses a lot of stuff. So if you import, you know, just Flask, like Flask itself is likely
to import a bunch of things. So once you kind of on, you kind of recurse to that dependency tree and
expand it, it's a massive dependency tree on the Python side. It's also a massive dependency
tree on the JavaScript side. Oh yeah. Big application made out of, you know, hundreds
of open source packages because we kind of need it all to build this full, like this, this application.
So dependency management, it's a little bit of a struggle when you manage such a big piece
of software that's connected to everything. Yeah. There's no joke. There's a lot of dependencies
here. So, but there's ways you can run it without worrying too much about that, right?
Yeah. I mean, you can definitely like just run the Docker container. You can tip install superset.
There's, you know, somewhat straightforward way to set it up locally and get things going.
Yeah. Yeah. It's, it's kind of interesting how like building application nowadays, if you think
about the dependency tree that go behind any kind of solution or application, that's not just a library.
Like library should, should have like very minimal requirements.
Kind of dependency trees, right? This should be self-contained and kind of focused, I think. But
here, I think for, to build such a large scale application, we just need to have a lot of
the dependencies. And then these dependencies have often a fair amount of dependency. I'm
surprised to see like, now we're looking at click for people, not necessarily looking,
but just click itself probably as a lot of like its own, like sub packages now too.
Exactly. And there's a lot of things that it wouldn't click to be into your, in your dependencies
here. I guess there's a, we'll talk about running in just a minute. And there's a lot of architectural
layers at play here. So you've got superset, but you've also got celery, you've got Redis,
you've got some database layers. There's a lot of technologies that people would know working
as a group that luckily Docker just takes care of for us. More like Docker compose.
Yeah. Docker, Docker compose and, you know, help charts. I think we have like a helm chart too.
It was always important for me to keep it such that you can kind of just pick install superset
and run a few commands and get it running locally. So you don't need to have, you know, Redis out of
the box and celery out of the box, similar to airflow and that way where I wanted to have like a very
self-contained thing at first. But then if you want to run any modern web app, you know, that does serious
kind of work and solve some real problem. It's likely that you need, okay, you need to have web servers and
application server, but you need to have the whole front end stack, right? Like something like when pack
and you probably have like front end infrastructure, just on the, like how you build your front end,
it gets pretty complicated quickly. Then you probably need async workers. So also then you need something like
Maccelery and something like Redis to as a message queue to talk to the async workers. Then you probably
want to start caching some things. So you need a caching back end for, for certain things. And then
you need to support an open source. You probably need to support different databases. So some people
might want to use MySQL as a backend or Postgres or some, some more other things. So then you need to
like optionally support these things through abstraction layer. So it gets complicated really quickly.
Yeah. I was really cool though, that you can just pip install it. And there's a more lightweight
version without going through all the details. Let's talk about getting, getting going, get it
running, exploring it a bit and hosting it. But before we do, I said like 15 minutes ago, two quick
comments before we talk about databases, let's just talk about the database thing real quick here.
Sure.
Over here at the bottom, you've, you know, obviously where your data comes from, we opened this,
you know, I'm pointed out that Excel is bad at getting data from different data sources. You know,
people have operational data, they have data warehouses, they have data lakes, whatever you call
them. Yeah.
Things like this, right? So there's a lot of different places people are putting data. Maybe just touch a bit on
on the database integration here. Yeah. And I think like in the context of this pod, this Python podcast,
too. So for us, we use SQLAlchemy very heavily. So SQLAlchemy is a SQL toolkit first, and then an
ORM built on top of it. And probably much more than that. But the way that we support first,
I would say the metadata database for superset, right? So in superset, when you save dashboards,
save visualization, save queries, that goes to metadata database. And we tend to recommend
Postgres and MySQL as the backend for the app, just to keep the state of the app somewhere in a proper
relational database. Sure.
That's one. And then we connect to all these databases to do analytics on them, right? And that's
what we're looking at here, the supported databases in the sense of like, what can we build charts off of?
And what can we enable data exploration around of? And then this is powered by SQLAlchemy. So that
means that anything that has a DBAPI driver and a SQLAlchemy dialect, and then maybe that's an
opportunity to talk a little bit more about the database abstraction and the Python world since we
have a Python centric audience. So DBAPI is a spec is one of the peps out there. I forgot the number of
the DBAPI peps, but I was like, you know, just a common interface for all the databases and Python.
So that's called DBAPI. And then SQLAlchemy, the SQL toolkit knows how to speak certain dialects and
builds an RM on top of things. And this is a PEP 249. So it came a little bit later in the story of
Python. I don't know what's the number. What's the latest PEP number? They're pretty high these
days, although they seem to be organized by my concept. Let's see. We've got some of the 8000 here.
Oh, I guess there's there's like some encoding in the number.
There's some kind of grouping. Yeah, I'm not sure exactly what it is. But it's 3,000 for a specific
thing in the 8,000.
I think so. But yeah, don't hold me to it. Yeah, I think so.
Okay. Anyhow, what you need in order to basically for Superset to connect to any flavor of database is a
viable DBAPI driver. And once that's built, SQLAlchemy dialects, SQLAlchemy dialects are fairly
easy. Like we've written in a bunch of API drivers and SQLAlchemy dialects in the past. They're not that
hard to implement. So that means it's pretty much anything that speaks SQL out there, you know,
we can talk to essentially. Yeah. Yeah. So we've got the standard MySQL, Postgres,
Microsoft SQL Server is probably a big one in the BI space because a lot of enterprises are back with
that. But it also has more unique ones like Snowflake and Druid and Google BigQuery and Firebird,
a lot of different places that people can talk to. Yeah. When we see, you know,
like the Superset community and the preset customers. So I started a company three years ago that's
essentially commercializing Apache Superset and offering a managed service so you don't have to
run it. So we're on call. You're on call. There's a freemium to say if you want to try Superset,
you can pip install Superset and kind of struggle with Docker and all this stuff. Or you can try it
directly at preset so you can just like start for free and see if it works for you. Then you can kind of
postpone the decision of like, do I want to run it on my own or do I want to use a managed service and kind
of pay as I go instead. But yeah. So what we see in terms of what our customers use, so a lot of Snowflake,
a big query, these cloud data warehouses can a no brainer nowadays. If you have a true analytical
workload, just put all your data and Snowflake, big query. And then there's still some Redshift and
there's still like, you know, all sorts of like, you know, database engines for whatever circle reasons
people have or they have constraints of them to run something, you know, on premise or in their cloud
and then Redshift. Right. Absolutely. So because it's open source, they can go and host it to their heart's
content or they can go SaaS style and work with you all. That's right. So for us, we do offer the
managed service as you know, the freemium and pay as you go can proceed. So it's like 20 bucks per user
for months. It's pretty, pretty straightforward and kind of easy to grow into and you pay as you go.
Then we have something called the managed private clouds. If you do want to run a managed service inside
your cloud because you don't want your data to leave. Maybe your data is not already in a cloud
data warehouse. Maybe it's inside your VPC and you want to keep it there. So we offer a service. It's
still a managed service with a centralized control plane, but that runs on your cloud. So we do offer
this and then you're always free to like run on your own. Right. Like to and there, the question is like,
can you know, you have to think the math of like running a piece of open source software versus
like running on your own versus like paying a vendor, like running Kafka or buying Confluent for events or
running Spark or Databricks is whether you're interested in the bells and whistle that the vendor uses. And
and then the constraint you have around like quality of service and think about total cost of ownership. So
the reality is like running something like superset at scale in your organization, if you want the latest,
greatest, secure, kind of patched up version of it is that it's pretty expensive to the total cost of
ownership of open source is fairly high. So often the vendors can do it at a better, better price and better quality.
To patch Celery and Redis and Memcash and databases and your servers hosting them and keeping them all
going. It's non-trivial. And then there's disaster recovery and failure. And you know, as soon as you
were thinking, well, maybe we should hire somebody to do this, then all of a sudden a paid service starts
to sound pretty appealing. Right? Oh yeah. I mean, when you think about like what it really takes to
manage a piece of software or collection of pieces of software, like, you know, superset and Kafka and
airflow and all these things, and you want it to be state of the art, you know, latest, greatest version
and kind of secured compliance, if compliance is a concern and all this stuff. Generally for,
for at least for smaller organizations, it makes tons of sense to like, you know, who's the best
people to run the software reliably is the people writing the software. Yeah. You know, even on things
like I preset, we have a multi-tenant version of superset that we run where you can't really have that if you
run out on your own. So that means we, how much we pay per cycle in terms of infrastructure costs
is going to be much cheaper than what you can get to running superset on your own. Sure. Not every user
is asking a, an active BI question all the time. So you got extra resources to share. And then you
provision for peak. It's a little bit the same with infrastructure, right? Like you, if you run a
database server on your own, you have to provision for peak access, where if there's a cloud service, then you
you have to provision the cloud vendor as the provision for the total peak across all the
customers. So yeah, there's tons of economies of scale there. And we passed that on to our customers.
Cool. All right. Well, let's talk about maybe getting started and just the first touch type of
experience before we run out of time here. You have a nice doc that says installing and using superset.
And I went for the easy way. So on my Mac, I have Docker for Mac already set up, which means I have
Docker and Docker compose. And so basically that's clone the repo, the superset repo, go in there and
then just run Docker compose pull and then Docker compose up on a certain definition file, configuration
file. And then pray that there should be a comment that says pray and hope for the best.
One thing that's really interesting is like, and I'm sure a lot of other like open source leaders can,
can kind of relate to that is that no one agrees on the best way to run something for production use
cases for sandbox use cases, and even in developer mode. Right. Like, so for me, I'm like, I freaking,
I hate Docker and Docker compose because I don't have enough control and I'll tend to just kind of run my own set of my
own environment. I run Tmux and I do my own builds and I prefer having more control instead of trying to understand
that abstraction layer that Docker and Docker compose is. So there's an alternative, I think, documentation
somewhere. And there's a big contributing MD that's more geared towards people like, how do I run my setup if I want to
actually develop on the tool? So somewhere on the superset repo, there's a computer contributing MD file that says,
here's if you want to develop with Docker, Docker compose, you do this. If you want to develop using more kind of a different,
like more raw level, how do you think?
Create your own virtual environment and go.
Yeah, that's it. If you want to, and there's some people use pyenv, pyenv. Some people prefer using like virtual and more directly.
So it's really hard to come up with a, we got a prescribed way to do it with a good documentation.
But then, you know, half of the people are going to go their own way anyway.
So say Docker compose here too, is like a lot of people prefer helm charts for Kubernetes.
So then we have helm charts, we have a Docker compose construct, then we do have other documentation as to how to do it.
But it's been really difficult to have a very clear prescribed way to do it and then maintain the different ways
that we can do it individually and keep them all working.
Sure. So as much as I'm not a huge fan of developing code in Docker, I do think this is a nice way for a low effort, first touch experience.
You're like, I just want to run it and log into the web app and see how it feels and play with it.
And you get, you know, all the various moving parts or you get celery and Redis and whatnot, which is pretty cool.
That's also kind of a map of how to run it on your own, right? So maybe you're like, oh, I don't like Docker compose.
I prefer, you know, my own version of something else, but I'm going to look at the Docker compose to see what it's playing and have the recipe.
That recipe is still very useful for people at different ways.
Sure. Or just knowing, look, there has to be, or maybe it's good if there's a Redis server.
Okay, well, I have Redis. Let me just set up a, set it up to connect to that one, for example, right?
That's it. Yes. I'm just going to change that part of the recipe because I already have that ingredient, you know, run.
Yeah, exactly. Exactly. When you run the Docker container, it says, you wait a moment.
It says, everything worked. Go over to localhost 8088 and log in.
The super secure default password and the username is admin admin.
So you're going to change that, but, but, you know, it's an easy way to get in there.
And what you get is you get some example dashboards and some example charts, right?
You want to just maybe tell us about the things we find when we get here so people know how to go explore when they get started?
Right. And you probably want to zoom out a little bit because like the rendering here, it's going to look a little bit better.
It's kind of interesting too, because you don't, out of the box, you don't get the thumbnail backend.
So you don't get the pretty thumbnails, you know, that will have a preset or that you can set up if you spend a little bit more time on setting up your salary backend and getting all the thumbnails to compute in the backend.
Yeah. So what you get out of the box is a set of very small data sets and charts and dashboard built on top of that.
You can navigate and play with.
If you really want to get value and get a real POC, you probably want to connect to your real data warehouse, probably not out of your local, but get to a slightly more, or maybe you have a copy of your data warehouse or some data you want to play with.
And you can connect here. If you were to look at.
It's data sets, right?
So data sets are like coming from your database connection. So somewhere in the upper right, you have settings.
I see.
Right. So you could connect database connections right here. So you could create a new database connection on the upper right. If you click, you'll see, you know, just a screen to connect to your database.
So you pick the database you want to connect to, add your connection string, and then you can start playing with your own data.
If you don't want to play with your own data, you can play with the data we provide. It's fairly limited.
We've spent a lot of cycles working on adding the latest, most fun data sets to play with, with the best dashboard examples, but allows you to get started and get a sense for what superset can do.
Yeah. So we have a couple of major building blocks. We have dashboards, we have charts, we have data sets, and we have the SQL IDE thing.
That's right.
I'll pull up a, here, we'll pull up a sales dashboard. Nothing screams BI more than sales dashboard.
That's right. We've started to have a, you know, an example there, but it loads like a few bar charts and it's not like the best design dashboard. It shows that we support.
But it looks good. Like there's a lot of, there's some beautiful stuff here.
Yeah. You can do so much more. I feel like our examples are dated. You can do so much better with like superset. If you actually take a little bit more time, we should work on our examples as a community.
You know, it's like really compelling data sets to play with, but it gives a good overview. And here, if you click on the dot, dot, dot for any chart. So here for people who can't see the visual support and click on edit chart.
So that will send you to our Explorer. So we're in the dashboard. We're looking at a specific chart. Now we just move to our chart editor. That's very much like your exploration. So here you can click on a metric. You can drag and drop different metrics.
Change my sum to max and see what happens. There we go. Look at that. Biggest sales instead of most.
Yeah. So you can update the charts and if you were to click on view all charts, I don't know if you see that somewhere at the top metal somewhere.
There's all sorts of visualizations that are supported here. You get a big list of all the visualization plugins that ship with superset today.
So all your common charts, but also some geospatial stuff and some more, some more advanced and complicated charts.
Nice.
All sorts of things. Yeah. So that's here. Maybe like just to do a little bit of the flow of the demo.
Apologies for people not watching and just look at it. So hit cancel and then click on the upper right dot, dot, dot.
So not settings, but the dot, dot, dot here. So you can say view the query or run in SQL lab will allow you to go kind of step deeper.
Where now the SQL that happened to be running behind this chart. Now you can, you can alter and, you know, push your own analysis.
Oh yeah. That's cool.
So we went from a dashboard to kind of your exploration session and into a SQL IDE. You can go deeper here and just like run your own analysis.
It's a big playground for data, you know?
Yeah. And you get a little, pull up your table or your SQLAlchemy model. Maybe it is. I'm not sure.
And call it like a schema navigator. So in this case, it's very much like you're navigating your database, your database kind of object. Right.
So you can navigate your schemas and see the tables and the views. And then there's good autocompletes. It's very much an IDE. If you start typing, you know, it will autocomplete the table names and then the column names.
Yeah. Super cool. You also get a query history. That seems nice for if you're like playing around, you're like, oh, five versions ago of typing in this. I had the picture I wanted and I know where'd it go, right?
Yeah, totally. So I think that for the people who speak SQL, you know, they can go deeper and run more complex analysis.
Sure. Yeah. Very neat. All right. Well, maybe let's close it out with a quick conversation on this and then I know we're out of time.
I picked on Excel for having very poor source control options. What about, what's the story here about versioning and sharing and collaboration?
There's this thing in BI called Headless BI. It's the ability to manage BI assets as code.
Add preset. We have built a CLI on top of the superset API. It allows you to import and export objects from into the BI tool to the file system.
So it's really easy to say, I want to store this dashboard or this set of dashboard or this set of object and manage them as code.
So there's a CLI that allows you to push and pull from the BI tool from superset into Git and GitHub.
All right. Let me see if I got this right. So I might create a folder in it that is a GitHub repo or a Git repo rather.
Then I would export all my stuff, commit that, and then I would just like write over it and keep committing.
Those would sort of track my changes. And if I ever need to, I can reinstantiate or rehydrate that thing out of the file set into superset.
Yeah. So there's more to it than that. And I'm going to try to explain it well. But once you say hit the eject button, which would be exporting the BI assets as code, then you get a collection of YAML files that represents your chart, your data sets and your database connection definition.
Right. So your dashboard then is represented as code. When you push things. Well, so first you can template eyes things at CML. So you can use Jinja, which is a great Python package to template files.
So you can inject some templates into your BI tool for if you were to say broadcast this object to multiple superset instances or to say I'm going to do permutation of variation on a theme.
You can do that through templating.
Okay.
And that's through the preset CLI and you can push. As you push, then there's a flag. I believe the flag is on by default where it will prevent people from updating the object in the GUI saying this object is managed as code.
The source code lives here for reference. So you can click and go see the code on GitHub. But then you can't save it because it's essentially read only and managed by source control.
I think in the future, we're looking to have a companion for each superset workspace on preset to be able to have the full history over time of what has changed. So you can go and restore assets, you know, as they were a while ago.
There's always someone that's going to delete something or delete a dashboard or change it in ways that are that are destructive and people want to roll back. So it's possible to do that.
Sure.
It makes a lot of sense to have some kind of source control story. But at the same time, because it's kind of a SaaS thing, either self-hosted, your little baby SaaS or at a preset, it's kind of a shared asset that doesn't need to be synced and pushed and pulled and cloned as much to allow people to work on it. Right.
Yeah. So there's different things. I think the Google Docs approach, which is to keep a GUI revision history and being able to see who changed what went is also valuable.
And sure, we're going to see that in the future of superset too, being able to say, I want to look at the history of this dashboard from a GUI perspective.
So that's something that has been requested and will have in the future. So call it your Google Docs kind of GUI.
Yeah, that's true.
The managing asset as code is different use case, right? If you have an embedded dashboard or if you publish a certain dashboard as part of your application, that's more the rigor. Like, I want to have it in source control. I want a version. I want it, you know.
Sure.
It's kind of like having a DevOps team versus, you know, someone keeps the server running. Right. Like there's different levels of maturity around different things and companies.
Yeah, people want that flexibility too. Like infrastructure as code, for instance, is great. But that doesn't mean that everything should, like if you and I want to go and create a AWS account and spin off some resources, maybe we don't need to start with, you know, Terraform script.
Yes, exactly.
And then you can generate the code later. Maybe you can say like, hey, AWS, can I generate the Terraform code of all the stuff that I've done in the past three days so that, you know, GUI to code can flow.
And then, yeah, the other way of like, you know, code to GUI. But yeah, it's important for this sort of tools, managing critical assets to have these workflows like GUI to code, code to GUI, and be able to have the flexibility and best of both worlds as you go up in your maturity lifecycle.
Yeah. And your need for rigor.
Makes a lot of sense to me. All right. Well, we are well out of time here, Max. So, you know, congrats again on creating such a cool project. And I guess with Airflow as well, it's not even the first one. So very popular. It seems like it's definitely taken up. It's great.
Yeah, it's been super exciting, like way beyond my expectation. And I think really often like the original creators get too much kind of recognition and reward compared to like the rest of the community, right? So what it takes for something like Superset to exist is it takes 800 people contributing and it takes an entire Slack community. And really often we give a lot of credit to the person who created the thing. But you should look at like how bad Superset was.
What was the first person, what the only person working on it and what it really took off is when we saw like a set of really good contributors coming in and pushing it to the next level.
Sure.
That's been rewarding.
That's awesome. I definitely got some people excited about it. One of the comments in the audience is this project has me stupid excited, which is lovely.
Love to see that excitement, right? Like a lot of this validation comes through usage and value and people getting excited, contributing and more like just using here. Like we'd love to see people just say like, hey, we're using this. We're getting tons of value.
Yeah. Go to the in the wild.
Yeah.
Put your scam on it, right?
I get like the communistic, like, you know, like together we can build better things than vendors on their own can. It's just like open source, a better way to not only to collaborate and build software, it's a better way to discover software, adopt software.
Yeah.
And just like get to solutions, you know.
Very cool. All right. Well, before you get out of here, final two quick questions. If you're going to write some code, what editor do you use?
As I feel, I'm still a Vim person. I feel like I need to modernize. I'm not like, oh, Vim is better than all the IDEs. It's just muscle memory at this point. It was just very common line and very kind of into Vim and like my specific kind of tune up for Vim. And it's not because I think it's better. It's just like habit, you know.
Cool. There's a funny guy who I think he's German. He does this YouTube series, making fun of different programming languages and communities. And one is this guy. He talks about how he fought in the Vim Emax wars. Yeah, it's pretty good.
All right. So you're on the Vim side. Fantastic. And then.
And I'm not on the side too. It's like, that's what I use. But at the same time, like encourage people to find something that works for them.
Sure.
Then I talked about the power of muscle memory, right? Like once you really know your tool set and the shortcuts, it's like your computer becomes an extension of your brain and your muscles. And there's just a beauty in that. So it's good to have a tool that enables you and to have that self-training. Like I'm going to train my muscle memory so I can do the things that I do all the time without things.
Right. You think I want this to happen and then it happens and you don't have to be conscious of it happening, right? In your editor, like that's the way.
Clicking around, I'm like, I'll do the sequence of like six clicks to do this thing. Photoshop all the time. Why can't you just do like command shift R plus V2?
Yes. Exactly.
You choose a sequence, it just happens magically.
Yeah, absolutely. And then notable PyPI package or other library fan, you're like, this is awesome. People should know about.
Yeah. So I wanted to talk about, so I live, you know, we use SQL very heavily, you know, as you saw. So if you're a data practitioner, you write a lot of SQL. I spend quite a bit of time writing tons of SQL in Airflow, a little bit in DBT too, more recently.
There's this like SQL linter that came out. It's called SQL fluff. It's been around for a little while people. So check out PyPI SQL fluff.
Right.
There it is. And it's a very configurable SQL linter fixer. So, you know, like we all love like Pep 8 and things like Black that are very deterministic and opinionated. I think we're not there in the SQL world. People have not agreed on our Pep 8 equivalent for SQL.
So this is like highly configurable. So you can agree with your team on the set of like linting rules for your repo and then it can fix a lot of stuff for you. So I think it helps.
If we're going to manage mountains of SQL, I don't like SQL that much, but it seems like this generation of data teams is going to rely a lot on a lot of SQL.
Then having a linter, you know, helps making that a little bit more bearable.
Excellent. SQL fluff.com. Very cool. All right. Final call to action. People are excited.
If you're excited about Superset, I want to get started. I want to play with it. What do you tell?
Pip install Superset. I mean, come to the GitHub repo. Check out superset.apache.org.
We haven't talked about the Apache Software Foundation too, but, you know, we're supported by the Apache Software Foundation in many ways.
And then you should be able to find tons of resources.
It is a little bit harder to get started than other things because it has such a broad piece of software that's like very, very layered.
We have a Slack. So I think there is a type of issue that's probably called like starter issues.
I forgot the exact name of it. So, and then we have a Slack to get involved.
And I believe in Slack, there's a way to kind of introduce yourself.
And there's a bunch of channels that are more like, how do I get started? How do I contribute?
So there should be outlets for anyone who wants to get involved to get connected.
If you fail at doing that, like you can probably reach out to me directly on Twitter or elsewhere.
And I might be able to give you some pointers.
Yeah, there's a few people commit to the project. So there's got to be a lot out there.
That's like a thing though, like when the project gets bigger and there's more contributors, that doesn't mean it's necessarily more welcoming and easier to get into.
There's more people, but sometimes there's not as clear of a, if you don't have it BDFL, sometimes a little bit harder to talk to a single person and get the exact pointer that you need.
So I would say like, just get on the Slack, talk to a few people, find, think about how you want to get involved too, and be clear about your intentions.
And then we'll be able to connect you in the right place, the right person.
Fantastic. All right. Max, thank you for being here. Thanks for creating this cool project.
Looks like tons of people are getting value from it.
Yeah. Thank you for having me on the show too. And I'm going to go and look back at the episodes and kind of, you know, I'm always looking for good content too, and keeping in touch with the Python community too.
So I'm going to go and dig in your archives there.
Right on.
And listen to a bunch of episodes.
We have seven years, almost every single week. So there's a bunch of episodes back there. So yeah. Thanks so much.
Yeah. See you later.
Thank you.
Take care.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show.
Join Sentry at their conference, Dex, Sort the Madness, the conference for every developer to join as they investigate the movement and trends for better and more reliable developer experiences.
Save your seat now at talkpython.fm/Dex.
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.
I'll see you next time.