In this episode, we'll be discussing two powerful tools for data reporting and exploration,
Dataset and Dogsheep.
Dataset helps people take data of any size or shape, analyze and explore it, and publish
it as an interactive website and an accompanying API.
Dogsheep is a collection of tools for personal analytics using SQLite and Dataset.
Imagine a unified search engine for everything personal in your life, such as Twitter, photos,
Google Docs, Todoist, Goodreads, and more, all in one place and outside of the cloud companies.
On this episode, we talk with Simon Wilson, who created both of these projects.
He's also one of the co-creators of Django, and will discuss some of the early Django history.
This is Talk By The Nome, episode 299, recorded November 18th, 2020.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities.
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.
This episode is brought to you by Linode and Talk Python Training.
Please check out the offers during their segments.
It really helps support the show.
Simon, welcome to Talk Python to Me.
Hi, great to be here.
Hey, it's great to have you here.
We're going to talk about some really interesting projects that you've been working on, some
that are extremely broad and far-reaching, and anybody who touches Python or maybe even
knows about it, and then another, which I feel is such a personal project.
It's for everybody, but it reveals so much data about you, you know?
Absolutely, yeah.
We're going to talk about Django a little bit, which you were part of creating.
We're going to talk about data set, which is a way to interact, basically put a UI on
top of any database in a friendly way that lets you explore it and treat it as an API.
And then Dog Sheep, which has a funny name, nice story around the name, that allows you
to basically take all of the data about you and turn it into your own Google.
Right.
It's your personal data warehouse, I've started calling it.
I'm fascinated by where that could go.
Now, before we get to all three of those cool things, let's just start with your story.
How did you get into programming into Python?
I learned to program with my dad on a Commodore 64 back in the 80s, and then kind of moved on
to early Windows and DOS, where you didn't really get to program anything from QBasic.
But I got really into programming when actually during the first dot-com boom, like even like
Web 1.0, 1999, 2000, when I was working in London for a online gaming company, a company
called Gameplay.com, which was doing like selling boxed games where you mail ordered them, but
also running online gaming servers for like Team Fortress Classic and Half-Life and Quake and
all of those kinds of things.
Oh, yeah.
Team Fortress and Counter-Strike.
I love that stuff.
That was so fun.
Oh, absolutely.
And so I was working for their online gaming division for a year and a half before the
dot-com crash and everyone got laid off and it all collapsed.
But during that time, I started the company as the downloads editor, so responsible for
the section of the website where you download plugins and patches and mods and so forth.
And I essentially taught myself web development as part of that and as part of some other gaming
related side projects I had.
And so, yeah, I'm a veteran of the first round of dot-coms back when no one had a slight
idea what we were doing.
Yeah, yeah.
Everyone was just making it up on the spot, right?
Oh, totally.
So when you were working on that web development stuff, it probably wasn't Python, I'm guessing.
Certainly wasn't Django because Django was what, 2005?
2003, 2004 when we built it.
I think it was open sourced in 2005.
Yeah.
Right, right.
Okay, so what were you programming then?
Oh, so Gameplay.com was running on a vastly expensive content management system called Media
Surface, which was a combination of Perl for templates, Java and Oracle under the hood and
insanely expensive and very, very tricky to get things done with.
And then I had side projects which were classic PHP and MySQL.
Right.
So I was very much the sort of the classic PHP programmer.
And actually, I mean, this is where Django came from is Adrian Holabati and I were working
together at this local newspaper in Lawrence, Kansas.
And we were both PHP developers and we saw the siren call of Python and wanted to figure out
how we could build websites using this.
We felt much more exciting programming language.
Oh, that's awesome.
It's definitely more exciting.
But I do want to ask you, it's such a different world, right?
We can go to the cloud providers and pay $5 a month and probably get better infrastructure
than you guys had.
I mean, who knows how much, right?
Enormously.
I mean, back then, a content management system, because you could spend a million dollars on
your content management system.
And they were terrible because nobody knew what a good content management system looked like.
This was back before things like WordPress as well.
Like your only option was to spend huge amounts of money on these like giant enterprise systems
and then cross your fingers and hope that they could work for you.
Yeah.
So how did you feel when you worked, you go to work, you work in this kind of like ultra
expensive, clunky environment and then go home.
And even though it was PHP, still like do PHP and MySQL and kind of like, I paid nothing
for this.
It maybe felt as good as what this crazy online system you guys are working with.
What was that back and forth like?
I don't think it did feel nearly as good, to be honest, because there was no open source
was still just starting up.
So if you wanted to build something in MySQL, you wrote everything.
Oh my goodness.
You would start with the authentication system and work on it from there.
So to be honest, I feel like today, like open source for me has solved the whole code
reuse problem.
How do we stop wasting our time to rebuilding the same things over and over again?
But yet, you know, 20 years ago, you just built everything from scratch and everything
took months to do.
It's really interesting because I started out in C++ and I felt like a lot of the stuff
I built was extremely low level, not just because it was C++, but because of this sort of difference
that you're talking about.
And throughout the years, I've seen it just get like what used to be really hard is now
just grab this library and plug it in.
That other thing used to be hard, grab this library and plug it in.
And it just seems like the natural consequence would be, well, we need fewer developers because
they used to have to build this.
Now they plug it together.
And yet all we've done is decided to solve more ambitious problems.
Absolutely.
In more interesting ways, right?
It amazes me the quality of software that we build these days, you know, like 10, 15 years
ago, we weren't writing tests for everything.
You know, the quality of the stuff we wrote was just abysmal.
And today we've got continuous integration and continuous deployment.
And it's really quite, it's really easy to get out there and analyze like 15 different
options and pick the one that's most, the one that is the highest quality.
Not only do you have CICD, you've got it for free in the cloud on demand, you know, on actions
that trigger it, right?
It's just, it's such a cool place, a cool time to be doing this stuff.
Definitely.
Yeah.
So before we get to Django, how about now?
What are you up to these days?
So these days I spent the last year at Stanford University doing a fellowship.
There's a fellowship program called JSK and it's journalism fellowships.
The idea is to get sort of journalists from around the world together at Stanford for a year,
thinking about problems facing journalism.
And I managed to make my own to it as a sort of computer scientist with journalism leanings.
And basically thinking about, okay, what are the open source tools that I can build that
can help make data journalism more powerful, more widely accessible?
And so a lot of the data set project was really accelerated by doing that.
It finished a few months ago.
The problem I'm having is that at Stanford, I was essentially paid to tinker on my own
projects and go after whatever I thought was interesting.
That sounds good.
And it's great, but I'm having real trouble stopping.
So now I'm not getting paid, but I'm tinkering on my own projects, going after things I find
interesting.
So I'm calling myself a consultant and I am available for consulting opportunities, especially
around the sort of set of tools that I've been building.
But mainly, yeah, I'm focusing on continuing to build out this ecosystem of tooling for
data journalism and related projects.
Yeah.
Well, we're going to get to those.
And they're definitely super interesting, the ones.
And like I said, this personal aspect, I think that could help a lot of people, not just journalists
for sure.
But let's talk a little bit about Django.
You mentioned that it came out of, what was it?
Journal Lawrence?
Lawrence Journal World or something like that?
Journal World.
Yeah, it's a tiny newspaper in Lawrence, Kansas, a town I'd never even heard of.
And this was back in 2002, 2003.
I was a blogger.
I had a blog about web development and about 100 other people had blogs about web development.
So we all read each other's blogs.
And Adrian Holovaty, who was a journalism and programmer, posted a job ad on his blog saying,
hey, I want somebody to come and join me in Lawrence, Kansas, building websites for local
newspapers.
And it coincided with my university course, giving me the option to spend a year in industry,
which is something that UK degrees do quite often.
So I could take a year out, get a student visa, which means I could track traveling, work in
different countries, spend a year working, and then go back and finish my degree.
And so the opportunities sort of aligned themselves.
And I had huge respect from Adrian, just based on what I'd seen that he'd been doing.
And it felt like a pretty interesting adventure to run off to Kansas.
Yeah, yeah.
That's a cool adventure.
And yes, so I did that.
So essentially, it was a year long, almost a paid internship.
But it was in Lawrence, Kansas at this little newspaper.
And it was a fascinating place because the family that owned the newspaper had laid fiber optic
cable around a bunch of states like a bunch of years beforehand, when everyone thought they
were crazy, and then sold the whole lot to maybe Comcast, one of these big companies.
So financially, they were very secure, which meant they could invest huge resources in their
local newspaper for this little town.
And so this newspaper, despite serving a town with a population of like 100,000 people,
it had way, way more resources than you would expect any local newspaper to have.
They had their own software engineering team who were building out the websites for things.
And because the family owned the local cable company for the town.
So everyone in the town of Lawrence, Kansas had broadband internet in 2003.
And that meant that the news websites could have like online videos and stuff, which no one else was doing, because what newspaper had an audience who could actually watch that kind of stuff.
So it was a really exciting place to be inventing like things around online news.
And we also had a very ambitious boss, this chap called Rob Curley, who basically wanted us to act like we were the New York Times, even though we were like six nerds in a basement somewhere.
This little local newspaper.
We had things like the local, there was a softball league where all of the local kids in softball teams competing against each other.
And it turns out this is an amazing thing for a local newspaper to cover, because if you have good coverage of the softball league, everyone who knows a child in your town will buy your newspaper.
So we went all in on kids softball and we ended up building a website for them that treated them.
The idea was to treat them like the New York Yankees.
So we had like player profiles and match reports and photo galleries.
And then we sent two interns out to take 360 degree photographs of every softball pitch in town.
And we had those on the website.
And this was like quick VR or something.
It was absolutely astonishing.
That's so, so neat in the early days.
Like, I'm sure the kids felt so special as well.
I bet they still have like saved copies of their time.
The best website we worked on was there was a local entertainment portal for the town of Lawrence, Kansas.
And it was basically a website that had the events calendar.
It had band profiles.
It had restaurant reviews.
It was like sort of a super hyper local version of Yelp crossed with music magazines,
crossed with an events website just for this one little town.
And we had features like there was a downloads page where you could download MP3s of bands who were playing in town that week.
Because we had the MP3s for all of the local bands, again, in like 2003.
And a little radio widget that you could click play on and stuff.
It was astonishing.
I have never seen an entertainment website since that was as good as this one that we were building back in Lawrence, Kansas.
This portion of Talk Python To Me is sponsored by Linode.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy, and scale your modern applications faster and easier.
Whether you're developing a personal project or managing large workloads,
you deserve simple, affordable, and accessible cloud computing solutions.
As listeners of Talk Python To Me, you'll get a $100 free credit.
You can find all the details at talkpython.fm/Linode.
Linode has data centers around the world with the same simple and consistent pricing regardless of location.
Just choose the data center that's nearest to your users.
You'll also receive 24-7-365 human support with no tiers or handoffs regardless of your plan size.
You can choose shared and dedicated compute instances,
or you can use your $100 in credit on S3-compatible object storage,
managed Kubernetes clusters, and more.
If it runs on Linux, it runs on Linode.
Visit talkpython.fm/Linode or click the link in your show notes,
then click that create free account button to get started.
I have a history with Lawrence.
I actually went to college there and got my math degree at University of Kansas.
No way!
I love that town.
I love it.
The Mass Street little downtown with Mass Street Brewery and all that was such a beautiful place.
I really enjoyed my time there.
Yeah, it's a great town.
I think when I was there, I'd never been to anywhere else in America, basically.
So it felt like a cool town, but I didn't really understand how cool it was until 20 years later.
I've now lived in America, and I've been to lots of towns, and Lawrence is special.
It's a very special.
It definitely is.
But what I never knew was how cool this newspaper was.
I mean, I was just like a kid in college.
I didn't read the newspaper a lot and whatnot.
So this is a really interesting cradle from which Django sprung.
So tell us about Django and how it fits into this world.
Sure.
So basically, Adrian and I, Adrian had built Lawrence.com, this amazing assignments website, in PHP.
And both Adrian and I had hit that point in our PHP careers where it was straining under the size and complexity of the things that we wanted to do with it.
This was like before PHP 4 even.
So classes were very new, and the PHP language was pretty primitive compared to what you have today.
And meanwhile, Python was exploding in popularity.
We were both huge fans of Mark Pilgrim's Dive Into Python and Mark Pilgrim's blog where he talked about this.
And so we decided that we really wanted to be working with Python for building these websites.
But the web options back then were not particularly – the main thing was Zope.
And Zope was pretty good, but it didn't match the way Adrian and I thought about the web.
We cleared about things like designing our URLs carefully and separating our CSS from our HTML.
The sort of modern MVC framework that people almost take for granted now, right?
Exactly.
But there weren't really any great options for that in Python.
So we were looking at ModPython, the Apache module, as the way that we would put Python on the Internet.
And we were a little bit worried about it because ModPython wasn't being used very widely.
And we're like, okay, what happens if we bet the newspaper on ModPython and it turns out not to work, right?
That would be –
Yeah, yeah, yeah, yeah.
So we said, okay, what we'll do, we'll have a very thin abstraction layer between us and ModPython so that if we have to swap ModPython for something else, we can do so.
And that basically is what – well, that was the initial seed to Django.
We wanted a request and response object, a basic way of doing templating, basic URL routing.
And so we built that out.
And we never thought it was a framework.
We called it the CMS, right?
It was the CMS of the newspaper.
And it kept on evolving these additional little bits and pieces.
Django admin was something which I went away to the South by Southwest Festival for like four days.
And when I came back, Adrian had written a code generator for admin websites that was churning out all of this stuff.
We just kept on building these extra bits out.
And then I went back to England.
My year in Kansas ended.
And about six months later, they open-sourced Django.
At the time I was working, it wasn't called Django.
There were various ideas for names, which are truly terrible.
But yeah, Jacob Kaplan Moss had joined the team at that point.
And yeah, they made the case to the newspaper that they should open-source this thing.
That's early days for that, right?
Like it's not – like now it would be easy sell.
But back then that was weird, right?
Well, yeah.
I asked them about this.
And apparently one of the arguments they used is Ruby on Rails had just come out and was just exploding in popularity.
And they could see that this company that released Rails was hiring people left, right, and center and was doing really well out of it.
So they went to the newspaper and said, hey, look, if we open-source this, it's a great way for us to get talent and get free fixes and all of that sort of thing.
And it worked.
Like you and I are sitting here talking about this small newspaper in Lawrence right now, right?
I mean, we wouldn't be doing this otherwise.
That's true.
But the argument that worked is they said to the newspaper owners, we've been building on open-source, right?
The newspaper – we run Linux and we run Apache and Perl and Python and we've used all of this open-source stuff.
This is a way of us giving back.
And that's the argument that apparently resonated with them.
They said, no, that completely makes sense.
We can give back in that way.
And yeah, and so Django open-sourced and it's been – that was 15 years ago, I think.
And it's just been growing in it ever since.
Yeah.
Did you predict – like you look around now, it's just ubiquitous.
Like does it blow you away what's happened?
Completely blows me away.
The thing that really amuses me is that I keep on seeing people talking about Django as the boring option.
And like Django and Rails, yeah, those are the safe, boring options for things.
And I actually saw someone on Twitter the other day say, well, nobody ever got fired for choosing Django.
And I was like – I actually – I direct messaged Adrian and Jacob with that quote.
I'm like, can you believe this?
That we are now – no one ever got fired for choosing IBM option for web framework.
Exactly.
Amazing.
Yeah.
I think there's definitely some truth to that.
Quite interesting.
It seems like it's got a ton of momentum.
It's really starting to embrace the async and await world.
It looks strong.
Yeah.
So a lot of my projects these days don't use Django, but they do use ASCII.
I am really into the whole – the ASCII ecosystem that's growing up is so exciting.
And Django is getting better at ASCII itself, so I'm going to be able to merge a bunch of my ASCII projects back into my Django projects pretty soon, which is super exciting.
Yeah, that's exciting.
I'm super excited about FastAPI, and it's one of those that fits really well in that world.
Yeah.
I mean, I haven't really done FastAPI, but I love Starlet, which is the framework.
Yes, that's the foundation.
Yeah.
Yeah, super cool.
All right.
Well, congratulations on Django to you and everyone who worked on it.
I do think it's really interesting.
If you look at the timing, Ruby on Rails came out of 37 Signals, now Basecamp, and was extracted from – they were using inside, right?
Yeah.
And they built it for them and extracted it.
You guys built it at the newspaper and said, this thing we can pull out of and make it something else.
I think it's really interesting that it was sort of polished and proven in this real place, right?
I think the way I see it is Rails was extracted from Basecamp, right?
They built Basecamp up.
They pulled a framework out of it.
Django, the goal was always Lawrence.com.
We had this entertainment website and PHP and MySQL, and we knew that we wanted the thing we were building to power that.
So Django was actually – there was an existing target, and we evolved the functionality of the framework until it could run a very high-quality newspaper, entertainment, listings, website.
And so it's almost – it's like one was extracted and one was evolved in the direction of supporting this one site.
Yeah.
It's neat to see.
I think they both came out quite successful from those experiences.
All right.
Let's start at the foundation of this recent work you've been doing.
And in some sense, it's sort of a natural progression, right?
It's in the journalism side of things is where the origin came from.
So tell us about Dataset.
So Dataset is – on its website, I call it an open-source multi-tool for exploring and publishing data.
Basically, it's a web application which you can point at a SQLite relational database, and it gives you pages where you can browse the tables and run queries.
It lets you type in custom SQL queries and run them against that database.
It lets you custom templates and how things turn.
It lets you get everything back out as JSON or CSV so you can use it for API integrations.
And it lets you publish the whole thing on the internet really easily.
So it's a lot.
Yeah.
And one of the biggest challenges I've had is how do I turn this into a bite-sized description that really helps people understand what the software does.
I'm at a point now where if I can get somebody on a video chat, I can do a 15-minute demo, and at the end of it, they come out going, I totally get this.
This is amazing.
But that's not explaining software.
It doesn't scale particularly well.
Yeah.
Well, let me see if I can, with my limited exposure to it and knowing somewhat where we're going, you have this data source that's pretty ubiquitous or can become ubiquitous in terms of like some sort of ETL with SQLite, right?
SQLite is everywhere.
What's beautiful about it is there's no, please set up the server and make it not run as root and then put it on your network and so on.
Yeah.
Right?
It's the magic of SQLite.
SQLite, it boasts it's the most widely distributed database in the world, which it is because it runs on every phone.
My watch has SQLite tracking my steps.
Every iPhone app, every Android app, every laptop, they're all running these.
Yeah.
Your phone.
That's crazy.
It's a file format, right?
It's a SQLite database is a single .db binary file on disk, which like you said, makes it so convenient because I don't have to ask a sysadmin to set me up a Postgres schema or anything like that.
I just create a file on my laptop and that's my new database.
Yeah.
And it's even built into Python, right?
It just comes with Python.
Yeah.
It ships in the standard library.
Yeah, exactly.
So that's super cool.
And it's great that we have this data format that if we either have data in there or you could do like an API call and then jam the data in there, right?
Like something to get it into that format, which is great.
But you can explore that with like Beekeeper Studio or some data visualization, SQL Management Studio.
But that doesn't work for journalists.
That doesn't work for getting it on the internet.
That doesn't give you like the transformations.
In some sense, I kind of see it almost like as a really advanced web-based like data IDE, but user-friendly.
Kind of.
Yeah.
But the emphasis is absolutely on publishing.
It's on getting it online.
And then it's on being web native.
Like everything in dataset can be got out as JSON as well as HTML.
It can all get beat.
It can return CSV to you.
It uses you pass the SQL query in a get in a query string so you can bookmark queries, all of that kind of stuff.
Yeah.
I think the key, that's really the key idea.
It's how do you take relational databases and make them as web native as possible and as cheap and inexpensive to host and to run as possible.
So you can take any data that fits in a SQLite database, which is almost everything, and stick it online in a way that people can both explore it and start like integrating with it as well.
And another key idea in dataset is dataset has a plugin system.
I've actually written over 50 plugins for it now that add all sorts of different things, different output formats to get your database out as an Atom feed or an iCal feed.
I've got plugins for visualizations that plot your data on a map or give you charts and line graphs and so on.
I just this morning released a authentication plugin that supports the IndieAuth authentication mechanism.
So you can use IndieAuth login to password protect your data, all of these different things.
And honestly, having a plugin system is so much fun because I can come up with a terrible idea for a feature and I can build it to plugin.
And it doesn't matter that that's just an awful idea that nobody should ever have implemented because I'm not causing any harm to that core project.
It's a super interesting idea.
I also think it might be a way to encourage others to contribute because they don't have to understand the whole system and be afraid of breaking it.
They just have to understand, like, here's the three functions I implement to make this happen.
Real dream there is when people contribute to open source, that's more work for me because I have to review their pull requests and figure it out and so on.
If you write a plugin, you can release that plugin to the Python package index and I don't even have to know about it.
Like, I can wake up one day and my software has new features because somebody built a plugin and shipped it, which I think is fantastic.
It's fantastic.
And they don't have to go through you as a gatekeeper, even if you might be super friendly and whatnot.
They just don't have to have that interaction, right, which is pretty cool.
Yeah.
So one of the things that's interesting about Dataset is the way you get your stuff online is you basically just run Dataset against a SQLite database.
And now you have this website that lets you explore it like you described.
So you say Dataset space, path to a SQLite file, and now you have a web app running, right?
So you type Dataset, name a file, hit enter, and it runs on your local laptop and you can start browsing it and exploring it.
But then if you want to put it online, I've been building out integrations with a bunch of different hosting providers
where you can, from the command line type, Dataset space, publish space, pick your provider, say, say Google Cloud Run, Dataset publish Cloud Run, name of database, enter.
And it'll upload that database to the internet, wrap it in the application itself, and give it a URL and start serving.
So it's like a one-liner for publishing data online with a URL that other people can start using.
And that's basically, that's enabled by all of these fascinating serverless hosting providers.
And that was actually one of the original inspirations for Dataset.
So I was looking at server hosting and saying, okay, what can I build with this that I couldn't have built beforehand?
And the limitation of serverless host is that they generally don't let you run databases.
They're like, you can run like a sort of stateless application that does stuff, it's fine.
But if you need to store data in the database, you're going to have to pay extra or get an RDS.
Right.
The only real option you have is please subscribe to our managed database service of some sort, which turns you into a DB admin and all sorts of stuff you don't want to be.
The realization I had is, hold on a second, that makes sense if you have to write to your database.
But if it's read-only, if you're publishing like interesting data sets throughout the world, which aren't going to change, why not just stick that data in SQLite and then put that .db file in as an asset as part of your source code?
Like basically bundle it in with the application.
Right.
It gets loaded in AWS Lambda or whatever, just like it's right there.
Yeah.
It's basically a giant loophole that lets you abuse serverless host providers, which are really cheap to serve interesting relational data.
As long as you don't need to accept rights, it just works, which I think it's kind of devious and it works incredibly well.
Yeah.
It's really interesting.
One of the things that I heard you say in a talk that we'll get to in a little bit is, you know, coming from Django, Django has the beautiful Django ORM, right?
Which is a really nice way to talk to data and manage it.
It's not so good for completely dynamic, unknown schemas, but it's good if you know it.
One of the cool things about ORMs that I really like is it makes it very hard to do to write bad code that has SQL injection.
Absolutely.
Yeah.
Right.
And yet what you said to me is, here's the thing on the internet.
I can go to it and then I can type in, edit the SQL directly.
Yeah.
This seems a little bobby tables all over the place.
Totally.
It's SQL injection as a core feature of the application.
And the reason it's okay to do that is that it's read only.
Like the data is read only.
I open the SQLite database file in read only mode and so forth.
And so the only damage you can cause by putting in an evil SQL query is you could try and write one that uses up too many resources.
But I've got a time limit on those.
So if your SQL query takes a second to execute, I'll cut it off and I'll return an error.
And yeah, it means that SQL is the API language itself, which is kind of fascinating.
People have been very excited about GraphQL over the past few years because it's a language that you can use to define exactly what you get back from an API.
SQL has been doing that since the 1970s.
So Dataset essentially gives you a JSON API that you can feed SQL queries to and get back the results in JSON.
Yeah.
It's really interesting.
The other problem that you can run into a SQL injection is exposing private data, right?
So if I want to say show, do a query that shows just my orders, but I'm allowed to get a or true into the query, I get all the orders, right?
But the whole point of Dataset is to say we're going to create just an explorer of all the data.
So there's no private data and it's read only.
So you're good to go.
Exactly.
And so suddenly SQL injection becomes this really powerful feature.
I've done some work where I've written JavaScript applications where the JavaScript, it creates a SQL query in the JavaScript and then it sticks it in the query string and runs it against Dataset and pulls back the results.
And the first time I did that, it was genuinely meant as a joke.
I was trying to troll my coworkers by saying, ha ha ha, look, I've got JavaScript that's injecting SQL statements into this thing.
It turned out it took me a couple of hours to build quite a sophisticated internal search engine for our documentation.
And it feels like running SQL in your JavaScript is a terrible idea.
But actually, for prototyping, it's really good.
Like you end up with about 20 lines of JavaScript that do something very sophisticated and let you build an interactive UI on the top of it.
Yeah, it's a pretty simple way to expose a searchable sort of REST API, read only REST API on top of just a data schema.
Exactly, yeah.
Yeah, but you have the ability to edit.
You go in there and you write some more SQL and you work with it.
And then you can say, give me the URL for this result, which I think is also a pretty neat thing, like deep linking into it.
The way I think about that is I've written applications, which is a SQL query.
Like it's a SQL query that is a great example.
I've got a database of all of my GitHub issues and issue comments across all of my projects.
And I wrote a SQL query which finds me GitHub issues which were created by someone who's not me and when none of the replies are from me.
So it's issues in my repos where I have not replied to them yet.
You basically somehow missed them potentially.
Exactly.
And so I've got a query for that and now I've bookmarked it and now I've got an application which is the here are the GitHub issues that you should go and look at application.
So an entire application ends up being a URL that you can bookmark.
And that's really interesting.
That's a really, again, a very web native way of thinking about the problem domain.
You know, you were talking about starting out working in the first dot com boom.
And one of the things that was all the rage back then were mashups.
Do you remember like Yahoo mashups and all that kind of stuff?
Absolutely.
Yep.
Talk Python to me is partially supported by our training courses.
Python's async and parallel programming support is highly underrated.
Have you shied away from the amazing new async and await keywords because you've heard it's way too complicated or that it's just not worth the effort?
With the right workloads, a hundred times speed up is totally possible with minor changes to your code.
But you do need to understand the internals.
And that's why our course, Async Techniques and Examples in Python, show you how to write async code successfully as well as how it works.
Get started with async and await today with our course at talkpython.fm/async.
So it sounds to me like what you can almost build here is like a super interesting mashup.
So you can like extract the data from GitHub.
You can extract it from over here and you put it together in this new form.
And then now you've got this API on top of it, right?
A massive realization I've had working on this stuff is lots of websites have APIs.
And the APIs sometimes have a lot of features like the GitHub API can do some pretty powerful stuff.
But I can always think of something the API can't do that they didn't predict I'd won.
If I can get all of my data out of that API and into a SQLite database, then there are no limits.
And any question I can think to ask, I can apply against that thing.
So I've basically sort of given the only thing I use APIs for now is to give get everything.
Just give everything.
It's here.
Download it and sync.
Get everything into a database.
And now I can start introspecting my data and building this.
Yeah.
I think where it gets interesting, as we'll see as we get on to like the final dog sheep side of things,
is it's great that GitHub has an API.
It's great that Twitter has an API.
It's great that Gmail has IMAP.
And all these different things have rich, deep ways to talk to them.
But if you want to talk to all of it at the same time and say, I want to know about what I've tweeted, emailed, or whatever else I've done about it.
Like, you don't want to try to build that integration of all those APIs.
Then it gets super gnarly.
But if you get it into some kind of SQLite database, all of a sudden it becomes an option.
Right.
It's this personal data warehouse idea.
And it's not just a personal data.
Like, as a company, if you're a company with 50 different Git repositories, which lots of companies have,
getting all of that metadata from all 50 of those repos into one place,
and I've got tooling that will let you do exactly that, is crazy useful.
It lets you build stuff across all of your issues and all of your comments.
It lets you talk about, like, here is what our software team as a company has accomplished,
or how many, like, that kind of stuff, right?
Which is still super hard, even if you go to GitHub and do that.
So I want to talk through a few examples that maybe we could mention really quickly.
You gave a talk that covered both Dataset and Dogsheep at PyCon AU online this year, right?
Was it this year or last year?
Yes.
Yes, I did.
It was this year.
Yeah.
So in there, you talked about all sorts of interesting things.
So I want to cover some of the examples there,
because they kind of, like, really made this stuff connect for me.
Cool.
Okay.
Yeah.
So the first one was, you said, let me just say,
we just search for random SQLite databases on my Mac.
And you said, oh, look, here, we randomly found one in the photos library.
Let's look at that, right?
You just pointed Dataset at that, like, search for it.
What do you do, like a .db or something like that in Spotlight?
Yeah, there's a Spotlight command that you can run,
which will show you every SQLite database on your Mac,
and it's fascinating.
Oh, my goodness.
The number of weird little databases that you already have,
your Firefox history, your Chrome history on there,
Evernote uses SQLite.
There was quite a few databases I found where I still don't quite know what they are,
but they've got things like places that I've been over the past couple of years.
I just sat there in a SQLite database somewhere, which is super interesting.
Yeah, for sure.
So in this demo, what you did is you used that command to find the SQLite database back in your photos library,
and then said, well, let's just pull that up and poke around, right?
Tell us about that.
Yeah, so the photos, this was always one of my sort of white whale was, I want my photos data.
I've taken 40,000 photos.
They've got timestamps and latitudes and longitudes and all of this.
How can I get that metadata into a SQLite database so I can run queries against my life in photos?
And I've tried getting this to work with things like Google Photos in the past.
Google Photos doesn't give you access to latitudes and longitudes, I think, for privacy reasons.
But anyway, the big realization I had was that the Apple Photos on your phone and on your laptop uses SQLite.
There's a little SQLite.
They've already done it for you.
You just got to go find it.
It's probably huge.
Yeah.
800 megabytes of data in one SQLite database file.
And it's not very easy to query because it's not designed for people to use it from outside.
But if you jump through a bunch of hoops, you can get that data back out again.
And then you start finding some really interesting things.
So obviously, they've got a record for each of your photos with when it was taken in the latitude and longitude.
They've reversed geocoded those locations.
They can actually tell you in the database, this was in San Francisco.
This was in the Mission District, those kinds of things.
But then the coolest thing is Apple use machine learning to identify what your photos are of.
So is it a dog or a cat or a pelican?
Right, because you can go to your photos app and search for that.
But like, show me cars and like some insane way cars come up.
Exactly.
But the beautiful thing about that is it turns out they run the models on your laptop.
Like Google and Facebook will upload your photos to the internet and put them in a data center somewhere.
Apple downloads these big binary machine learning model, like weights files onto your device.
They actually run it on your phone overnight.
And they use those to identify what's in your photos.
So from a privacy point of view, this is perfect because you're not uploading your photos somewhere for some creepy machine learning model to run against.
It's all happening on devices that you control.
And the results of that go in a SQLite database.
So they go into data set.
And yes, so I can get them out and get them into data set.
So yeah, I have a data.
I have an example query that shows me photographs I've taken of pelicans based on Apple's machine learning labeling, labeling my photos of pelicans.
And I can visualize those on a map because they've got lattes and longitudes with them and so on.
And then the really fun thing is there's this there are various clues in the photos app that they're doing quality evaluations.
Like if they show you all of your photos for a month, they'll pick a good photo to show us the sort of title of that album or whatever.
That's machine learning as well.
It's running on your device and it's based on these scores.
And the scores are sat there in the database and they have names like Z overall aesthetic score and Z pleasant camera tilt score and Z harmonious color score.
So you can say things like show me my pelican photograph with the most harmonious colors, with the most pleasant camera tilts and just get things back that way.
You could even set up like a walking tour of show me where I've taken aesthetic photos of pelicans, starting with the best one and then the next and then the next.
That is such a good idea.
Yeah, that's just a SQL query.
Yeah, yeah, yeah.
Order by aesthetic descending or something.
Yeah.
And there's also facial recognition, which again is trained by you and runs on your device.
So it's the least creepy version of it.
So I go on a SQL query saying, show me photographs of my wife, Natalie, and my friend, Andrew, and show me the one with the most pleasant camera tilt that was taken outdoors.
And this stuff all just works.
It's baffling and really super fun.
So one piece that we probably should connect for folks, if they tried to follow along, they find that SQLite database and then they throw a dataset at it, they're going to end up with like binary blobs where this data lives, right?
Oh, totally.
Yeah.
I think Apple's SQLite format uses like binary plists in some of the columns.
And also, it's actually quite hard to even open it because it'll crash and tell you that you don't have that custom something extension running.
So the way I've addressed that, I wrote this, I found this software on GitHub called OSX Photos, which is someone's open source library for talking to the OSX SQLite database and working around some of these weird issues.
And then I built my own tool on top of that tool called Dog Sheep Photos, which basically both pulls out the metadata for your photos into a nicer format, including getting the machine learning labels and stuff.
But it's also got a tool for uploading the photo files themselves to an S3 bucket.
Because if you want to really take control of your photos, you need them to have URLs so that you can embed them in pages and link to them and so on.
So I've got a whole tool chain for uploading all of my photographs to S3 and extracting the metadata into a separate database and then publishing that database with data sets somewhere so that I can run queries against it.
Yeah.
Yeah, super cool.
All right.
Well, I think that probably is a good transition over to Data Sheep.
So we have these different sources of data.
Like it's nearly unbounded at this point, right?
Of where data on the internet might live about that could be for you.
There was this firebrand of a character that you mentioned around Wolfram Alpha.
And he does some crazy, crazy, weird stuff.
But he also had this idea that inspired you to sort of try to bring those together and build it on top of the data set.
So like maybe start it with that story and we can tell people what Dog Sheep is.
Okay.
So there's this chap called Stephen Wolfram who is, he created Mathematica and Wolfram Alpha.
And he's the CEO of a thousand person company, which it turns out he's a remote CEO, runs the entire company from home, which is kind of fascinating.
Yeah.
And he has been for a while, right?
Like before it was cool.
Yeah.
No, absolutely.
He's been doing the COVID thing for years and years and years.
And so in February of last year, he published an essay called Seeking the Productive Life, Some Details of My Personal Infrastructure.
And this thing, I would thoroughly recommend everyone take a look just to marvel at quite how long it is.
He has spent 40 years optimizing every single inch of his personal and professional life.
And he wrote about all of it in one place.
Like he scanned every document he's worked on since he was 11 years old and got them OCR'd.
And he's got a green screen in his basement for giving remote talks.
And his heart rate monitor showed him that his heart rate is better when he's – so he had a standing desk.
But his heart rate monitor showed him that walking outside is better for his heart.
So he rigged up a sort of little tray mechanism so he could use his laptop while walking in the woods.
And it's just astonishing.
And I read through this essay thinking this is a lot.
Like this is not –
This is next level.
Right.
Totally next level.
But there was this one little bit in it that caught my eye.
He talked about how he has a personal search engine, something he calls his meta searcher.
And so he's got his own private search engine that searches everything, every email he's sent, every paper he's written, everyone he knows who might know things about it, everything he's read, all of the files on his machine, all in one place.
And I thought, well, that's something I'd like.
Like I would love to have one place with as much of my personal data from different sources in one place where I can query it.
Like I know I was talking to this person, but was it on iMessage?
Was it an email?
Was it over Slack?
Like where the heck did I tell them this thing that I need to get back?
Absolutely.
And combine that with, you know, your bookmarks and your GitHub issues and, yeah, messages and all of these –
Your tweets.
Oh, yeah.
And it felt like there was something interesting there.
And so I then – I'll be honest, the best idea I've had in all of this is I thought, well, it's inspired by Stephen Wolfram, but it's not as good as what he's done.
So if he's Wolfram, maybe I should be doing something called Dog Sheep, like as the less alpha versions of those animals.
And then I thought, well, he's got a search engine called Wolfram Alpha.
I could build a search engine called Dog Sheep Beta.
And that joke stuck in my head.
And I enjoyed it so much that I spent like 12 months on and off thinking with –
Yeah, I have to build this.
It must exist now that it's so good.
I have to put it.
Yeah.
So this entire project is basically – it's pun-driven development.
It's driven out of this pun that I came up with a year and a half ago.
And, yeah, so that's what I've been building.
And so the idea with Dog Sheep, it's basically an umbrella project for a whole bunch of tools around this idea of personal analytics.
Like what data is there about me in the world?
How can I get that data out of lots of different sources and get it into SQLite databases?
Because once it's in SQLite, I can run data set on top of it.
And now I've got this personal data warehouse of my data from all of these different sources.
And then on top of that, I can build a search engine, which I've now built, which ties all of this stuff together again.
And so, yeah, so I've been tinkering around with all sorts of tools in this category for, yeah, just over a year now.
And I've got – so right now I've got data in my personal Dog Sheep from Twitter.
I've got all of my tweets, but also all of the tweets that I've favorited.
And I've favorited like 30,000 tweets, but I can search those and see who I've favorited the most from and so on.
I've got all of my photos, as we discussed earlier.
I've got my health kit data from my Apple Watch, which means I can tell you my heart rate going back the last three years or something.
How do you get it off the Apple Watch?
So, again, Apple are really good for this kind of stuff.
They don't publish it to the – they don't upload it somewhere.
They keep it on your phone and on your watch.
But there's an export button.
In the health app on the iPhone, there's a button that says export my data.
And it actually creates a zip file full of XML on your phone and then gives you the option to like airdrop it to your laptop.
So I do that and I get a 300 megabyte zip file full of XML.
And then I write a script which reads that XML in terms of SQLite.
And so, yeah, so I've got all of that data.
The best thing about that is anytime you record an outdoor workout, like if you go for a run or even if you go for a walk, it records your latitude and longitude every few seconds.
And that's available in the data.
So I've got – so, like, within 10-meter maps of every walk I've taken for the past year, which is super fun.
I mentioned GitHub.
I've got all of the data from all of my GitHub projects.
I've got over 400 repositories now.
So that's actually quite a lot of stuff.
I use Foursquare Swarm and check-in to places.
So I've got 4,000 swarm check-ins.
Oh, you have Google Takeout, which is insane.
Right.
I've only done a little bit of work with Google Takeout.
That's one of the least developed tools.
But, yeah, you can get Google's version of your location history, which is – like, for me, it's like 250,000 latitude, longitude points that they've – I don't even know where they got that stuff from.
Yeah.
I recently did a Google Takeout, and I think it was probably zipped.
I think it was 61 gigabytes or something.
I mean, it's a lot of data.
It's a lot of data.
And a lot of that is, like, photographs and document files and stuff.
But there's just a ton of very detailed JSON data about you as well.
With those exports, it's always fun to look for the ad targeting stuff because you'll find out that you have been assigned the role of a, like, middle-aged tech executive or something.
And you can see what they're targeting ads are actually based on.
I've got Evernote.
I've got, like, 600 notes from Evernote.
My Goodreads data on books that I've read, which is synced from my Kindle.
Oh, and then the most fun one is I've got a copy of my genome.
Because I did 23andMe a few years ago.
And I found out they've got an export button.
And you can get back a CSV file of 600,000, like, gene pairs from your genome, which I can now run SQL queries against.
So I have a SQL query that tells me what color my eyes are based on interrogating my own copy of my genome, which delights me.
That is pretty amazing.
That's just insane.
Yeah, so that's a ton of data, right?
This is a lot of stuff.
And I'm barely even scratching the surface of what I could be doing into this system.
Right.
Well, and these are all, like, plugins or other types.
So it's wherever the data lives.
If there's an API or web scraping, you can have it.
Right.
And it's some, the tools are all called things like Twitter to SQLite or GitHub to SQLite or I think I've got genome to SQLite somewhere.
That's just the naming convention that I use.
But, yeah, the core idea is you knock out a quick Python command line tool, which either takes a zip file you got from somewhere or hits an API with API credentials.
And it slurps down as much data as it can, wallops it in a SQLite database, and that's all it does.
And then it's up to you to run data set against it and start doing the, like, doing fun querying some things.
That's cool.
So I think maybe it would be good to connect this, maybe tell a story or an example, again, what you did at PyCon and you talk about your dog and figuring out using Twitter to graph the weight of your dog over time and Twitter to map where your dog likes to go on walks.
Absolutely.
So my dog is called Cleo.
First of all, tell me how dog and Twitter go together.
Not dog sheep, but just like your dog.
So Cleo has a Twitter account because, I mean, to be honest, most dogs have Instagram these days, but Cleo is a bit more old fashioned.
So Cleo is on Twitter.
She's more on the tech side, less on the young influencer side.
Yeah, exactly.
Got it.
Cleo, C-L-E-O-P-A-W-S.
Cleo pause on Twitter.
And she tweets about things.
She tweets selfies and like things that she likes and so on.
And every time we go to the vet, she tweets a selfie of herself at the vet and they weigh her and she tweets how much she weighs.
She tweets, I weigh 49.3 pounds.
I grew more dog.
And there's a selfie.
And one of the things I've done with dog sheep is I've imported all of her tweets.
And so now I can run a SQL query that just pulls up the tweets where it contains LB for pounds and or weigh.
So I can pull back just the tweets where she said how much she weighs.
And then I've got a regular expression extension for data that adds a custom SQL function that can do regular expressions because that's a useful thing to have.
So I can pull out her weight with a regular expression into a separate column.
And then I've got a charting plugin that can chart something against something.
So I can chart date against weight and see a chart of how much she weighs based on her self-reported weight in the selfies that she's posted on Twitter, which is clearly a...
That's a killer act right there.
That is a useful thing.
It's absolutely frivolous.
But what I think it shows is so interesting is what you can do if you can put these pieces of data together, right?
If all of a sudden I can just do arbitrary queries and apply some special filtering, but to these other data sources you never expected to be able to, all of a sudden you have a graph that you never knew you were keeping about the weight of your dog or some other thing you're interested in.
This is just a SQL query.
The SQL query goes in a bookmark.
So the entire application, the show me a chart of my dog's weight based on her selfies is a bookmark.
It's just a bookmark that I've got.
It's actually super useful.
Super cool.
Now, how do you get a map of where your dog is from Twitter?
So that one, I mentioned I use Foursquare Swarm and I check in places.
Every time the dog's with me, I use the wolf emoji in the check-in message, which looks a little bit like her.
And it turns out SQL does emoji these days.
So you can run a SQL query where you look for things like percentage wolf emoji percentage.
Right.
It's just a character that's unique.
Exactly.
So then you get back the check-ins where my dog was there.
And then because I've got a latitude and longitude in that query, I get them on a map.
So I've got a map of places my dog likes to go based on the wolf emoji in my swarm check-ins.
And again, it's just a bookmark.
It's these custom applications that's a bookmark.
I think those two examples really bring home the unexpected power of what you kind of unleash when you get this stuff.
Completely.
There's a project I should mention that relates to this.
So I've been writing a lot of these tools that create SQLite databases.
All of these dog sheep tools pull something from somewhere and turn it into SQLite.
And the way I do that is using a Python library that I've been building called SQLite hyphen utils.
SQLite utils is a bunch of utility functions to make it really productive to create new SQLite databases.
So the core idea is, say you've got array of JSON objects.
You can say dot insert bracket array of JSON objects.
And it will create a SQLite table with the schema that's needed to match those JSON objects.
Wow.
So it just looks and says, these are the top level keys.
So we're going to make those columns, something like that.
These ones are integers.
These ones float.
This is a text.
And it creates the table automatically.
Which means if you're working with an API that's well designed, like the GitHub API returns lists of JSON objects.
So it's a Python one-liner to turn those into a SQLite table with the correct columns.
And you can say, oh, and make the ID one the primary key and set these up as foreign keys and those kinds of things.
And that's been crucial because it means that I didn't have to come up with a database schema for Swarm and Twitter and GitHub and Apple Photos and all of that.
I just had to get the data into a list of objects and the schema was created for me.
No, it's got a little bit of a NoSQL feel in SQL.
Exactly.
And SQLite, it turns out, can deal with JSON as well.
So you can stick a JSON document in a SQLite column.
And then there are SQLite functions for pulling out the first key of it and that kind of thing.
But yeah, it means it's all super productive.
SQLite utils also comes with a command line tool.
So for simple things, you don't have to write any Python at all.
You can W get a JSON blob, pipe it into the SQLite utils command line tool and tell it to insert it into a table.
And it will create a database file on disk and populate the table.
And then you can do stuff like configure full text search against it or set up extra foreign keys or whatever it is.
Oh, that's super neat.
So all of these different integrations that you built, it sounds to me like they could potentially just be useful for people listening and go, you know, I'd really love to get four square swarm data as a SQLite database.
And they don't necessarily want to use dogsheet.
Like it sounds like these plug in pieces might be cool building blocks.
If you can get yourself a OAuth token for your swarm account, which I've got an online tool that will do that for you.
You pip install swarm to SQLite and you type swarm hyphen to hyphen SQLite swarm dot DB --token equals that and hit enter.
And that's it.
That's it's like a one line on the terminal.
And that will give you a SQLite database with all of your swarm check ins in it.
Wow.
I'm pretty fascinated by the idea of like I could go to one place and just search everything about me.
Absolutely.
So that feature, because I had this stuff in like hundreds, dozens of different databases and tables.
I actually built the dog sheep beta search engine just a couple of months ago.
And basically the way that works is you give it SQL queries to run against all of your other tables.
So you say for the GitHub one, select title from issues and create a date and so forth.
For the Twitter one, select this, select that.
And you run a script and it will run those SQL queries against all of your like 20 different databases,
load the results into a new database table and set up full text search on it.
So it's kind of like using something like elastic search where you have to query your data from lots of different sources into one index.
And in this case, the index is just another SQLite table.
And then that gives you a fasted search index on the top that lets you search across all of the different things that you've ingested into it.
Right.
If you do an index, it'll be nice and fast.
And then you just say, well, you've got to go back to these five tables and get these various things.
Right.
Yeah.
And that's actually part of the tool is you can then set up a SQL query for each type of content that says, oh, and to display it, run this SQL query to grab these details, stick them in this Jinja template and stick that on the page.
So when you display the results, it can use all of the rich data that's come back.
But the actual index underneath it is basically title content and the date and that's it.
Yeah.
Wow.
Okay.
Pretty interesting.
What about email?
I don't see in this list like connect to email, although there's Google takeout.
That's not exactly necessarily the same.
I will admit I have not done email yet because I am terrible at email and I'm almost a little terrified what will happen if I start running SQL queries against 10 years of mostly unread emails.
But I'm sort of transitioning into doing freelancing and consulting.
One of the most important aspects for consultants is that they're on top of that email.
So I think that's probably the next task that I'll have to take on is getting good at email and then ingesting that into the dog sheepers.
Yeah.
I mean, it's kind of like this open plugin type of architecture.
So someone else could create it as well if they're listening and they just want it to exist, right?
Absolutely.
I mean, honestly, like, you know, the email standards are good enough now that writing a tool that turns your email archive into a SQLite database is pretty trivial.
Apple mail.app uses SQLite anyway.
So I've actually done a little bit of poking around just looking at that database.
Okay.
Interesting.
Yeah.
I just haven't got to it.
You could probably point it at an Outlook PST file if, you know, the world has cursed you and like you have to work in Outlook.
Or you just use IMAP or POP3 or something like that, right?
There's a very solid Python library for reading Outlook mailboxes.
So you could totally use that.
Okay.
And then it would be a very thin layer of code on top to turn that into a list of JSON objects and pipe them into the SQLite library.
Yeah.
All right.
Super cool, Simon.
This is like a bunch of levels building on top of each other.
I like it.
And also thank you for the history of Django.
It was really cool to hear how you experienced as it came to existence.
That was neat.
Cool.
Yeah.
Could talk about a bunch more, but I don't want to take all of your time.
So let me just ask you the final two questions here.
I always ask.
So if you're going to write some Python code, what editor are you using these days?
And these days I'm all about VS Code.
Especially the most recent version of their Python integration, which is controversial because it's the one bit of it that's not open source.
But that thing is just miraculous.
Nice.
PyLance, right?
I think so.
Yeah.
It's showing me, hey, this variable hasn't been used yet and this import wasn't working and all of that kind of stuff.
See, I'm all into VS Code now.
Yeah, okay.
That's definitely one that seems to be coming along and catching a lot of traction.
Cool, cool.
Notable PyPI package.
Something you've run across that you're like, oh, this thing is cool.
You should really know about it.
This is great because I get to answer this using dog sheep.
Because I've got all of my starred GitHub repos are pulled into my database, into dog sheep.
And I can actually run a dog sheep, a beta search and say, show me everything I've starred or sorted by most recent.
So the most recent Python one I started, I just started Astor, A-S-T-O-R.
I've heard of that.
I forgot what it is, though.
Yeah, it works with the Python abstract syntax tree.
So it's for building software on top of Python.
And the reason I found it is that I found this tool called Flint, which re-does all of your .format calls and turns them into Python 3.6 format strings.
Yes.
And I was like, oh, how does that work?
And it turns out it uses Astor under the hood.
I was actually going to give a shout out to Flint.
The reason was on Dataset, I just saw the last commit at the time of the recording was use F-strings in place of format.
And you can just point Flint at the entire, just the top level directory and it just fixes it.
That's why I started.
I was playing around with that.
And then the other, I mean, the other one, it's not a recent favorite, but I'm going to promote HTTPX.
Oh, yeah.
I'm a big fan of that one as well.
You talked about the ASCII side.
This is like consuming services from inside an ASCII server.
Yeah.
One way to look at it, it's the new requests, right?
It's essentially, it was almost, I think, called requests three at one point in its history, but it's basically the modern version of requests with full async support.
So you can use it synchronously and you can use it asynchronously.
But the killer feature from my point of view is you can instantiate a HTTPX client and you can point it at a Python ASCII or WSGI object and then start running requests through it.
So it's an amazing test harness.
Oh, yeah.
All of the dataset tests and every dataset plugin that I've written, they're actually, they're using HTTPX.
So it's like being able to do HTTP testing.
You don't even have to spin up a local host server.
It's all happening in memory.
And that's just extraordinary.
Oh, that sounds fantastic.
Like that's such a good product of writing unit tests against things.
Yeah, I've never tried it.
But a lot of times you can create, you'd like install the web test and then wrap it in a test framework.
Or, you know, maybe you've got to even run it, like fire it up and run it and then talk to it.
But this is just like connect the two pieces in code and skip the network and go.
And I've got a really nerdy thing that I've just started doing with it.
So dataset has plugins and dataset plugins can do a bunch of different things.
But I realized that dataset itself is an API.
The whole point is that it gives you a JSON API that you can use to interrogate your tables and run queries and so on.
And I wanted my plugins to be able to use that API.
But I didn't really want them to be making outbound HTTP requests against themselves and so on.
So I just a couple of weeks ago added a feature to dataset where it gives you an internal call.
They can say client.get brackets and then feed it a URL.
And that's actually using HTTPX and ASCII under the hood.
So the idea here is that any feature of dataset that is an external JSON API is now also an internal API that plugins can use.
And I've started building plugins against that.
The Dogsheep beta plugin actually runs internal searches against the dataset search API for things like adding faceted search and so on.
Dataset GraphQL is a plugin I'm writing that adds a GraphQL API on top of dataset.
And that's going to be using this client as well.
So you'll run a GraphQL query which gets turned internally into an internal JSON query and runs over this ASCII mechanism.
It's cool.
I hadn't really thought about that with HTTPX.
I've always used it to just like I'm doing some async methods.
So here's a good choice for a client.
Yeah.
The deep integration with ASCII I think is really exciting.
Yeah.
Super neat.
All right.
Well, those are all good recommendations.
Now, final call to action.
People are interested in dataset.
Dogsheep.
First, I just want to throw out you should really go watch the 25 minute or whatever it was talk that you did at PyCon AU.
That'll connect a ton of things for people.
I'll throw in another recommendation.
Yeah, go for it.
I gave a talk last week, the GitHub Octo Speaker Series, which I think is the best talk I've given about dataset and Dogsheep.
It's got a lot of very recent demos in.
And that's linked to on my blog.
It's a talk about building personal data warehouses.
But yeah, that's got dataset and Dogsheep demos.
Yeah, very neat.
And also, you actually, this is somewhat unusual for an open source project, but I think cool because promoting open source projects is always like, you know, why do they take off or don't?
You have a dataset weekly newsletter.
Yes, I do.
It's not quite weekly.
Maybe I should have picked a different name.
But yeah, I've got a newsletter which goes out every week or so with the latest from the dataset ecosystem.
So that's dataset.substack.com.
My blog, Simon Willison.net, I update at least once a week with all sorts of bits and pieces.
And then if you're interested in the Dogsheep stuff, I would love it if people started building these themselves.
There is quite a bit of assembly required.
All of the code that I've written is open source, but you have to track down your authentication tokens and run cron jobs and find somewhere to host it.
And so it's not easy to get up and running.
But if you do get it up and running, I would love to hear from you about what kind of things you managed to do with it.
And if people want to build tools that are part of this ecosystem, I'd be absolutely thrilled.
Yeah, that'd be awesome.
If they want to build a star to SQLite, whatever star is, let you know, right?
Well, congratulations on this project.
I think it's super neat.
And thanks for coming on to share with everyone.
Awesome.
Thanks a lot for having me.
You bet.
Bye.
This has been another episode of Talk Python to Me.
Our guest on this episode was Simon Willison, and it's been brought to you by Linode and us over at Talk Python Training.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy, and scale your modern applications faster and easier.
Visit talkpython.fm/linode and click the create free account button to get started.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher 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.
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.
Bye.
you
Thank you.