There's a whole spectrum of Python web frameworks.
On one end, we have the micro frameworks like Bottle, Flask, and to a lesser degree, Pyramid.
On the other, things like Django or even CMSs like Wagtail,
which are built on top of Django way in the far end of the spectrum.
While this is often positioned as an either-or choice between these frameworks,
this week you'll meet someone who's doing a lot to build some middle ground in the spectrum.
Ian Dennis Miller, the creator of Flask Diamond,
an extension of Flask which brings the good things from Django to Flask's simple and small API.
This is Talk Python to Me, episode 97, recorded January 16, 2017.
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.
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 Rollbar and Hired.
Thank them both for supporting the show.
Check them out at Rollbar and at Hired underscore HQ on Twitter and tell them thank you.
Ian, welcome to the show.
Thanks for inviting me.
Yeah, I'm really excited.
I often feel like we have to make this tradeoff between micro frameworks when we're choosing
a web framework like Flask, to some degree, Pyramid, Bottle, things like that, or Django,
which has all these cool building blocks.
And I think you're kind of here to dispel the fact that that's the choice to some degree,
right?
I hope so.
I think there's room for something that exists somewhere in between, or maybe that can look
like one thing sometimes and look like the other thing other times.
Yeah, absolutely.
So we're going to talk about your project, Flask Diamond, which brings some Django-like features
to Flask.
But before we get into those, let's get your story.
Where'd you get into programming?
Yeah.
Many moons ago, in, let's see, I guess, sixth, seventh grade, something like that, I made
some kind of transition from using the computer basically as a gaming device.
And I started experimenting with this weird program I found lurking in the DOS prompt called
GWBASIC, which was a basic interpreter that just shipped with DOS.
And I actually started off by entering random words into BASIC because I didn't really have
a book for it.
And the internet didn't exist at the time, at least not the way that it exists now.
You didn't want to like gopher for BASIC?
Yeah, right.
Now, gopher.
So, I mean, you know, as a sixth grader, all that stuff was way beyond my reach.
But I guess kids just, our time is worth so little.
We sit there and we can just pound away at a keyboard.
And eventually, randomly, things started working.
And it took years, actually, of doing this.
But I learned how to program in BASIC.
And then as I grew up, I was able to take courses at school.
And so that actually accelerated the process dramatically.
Yeah, that's really cool.
It's amazing that you actually were persistent to do that.
That's really quite incredible.
Oh, yeah.
You must have thought like when you got to a program in a class, you're like, you mean they
give you all the stuff you could tell?
You just put it together?
This is like, nobody's, I could do this.
This is easy.
I could not believe it when I learned about a for loop.
Because I had discovered this.
So in BASIC, you can use a go-to expression.
And when I put a logic test inside a go-to loop that just kept looping across itself.
And when I got that test to break out of the iterator, you know, that was like discovering the wheel or something.
And so then when I learned that other programming languages had that built in and they called it a for loop, that just blew my mind.
I mean, everything that came with these high-powered languages like C.
That was so awesome.
Yeah, that's great.
Yeah, so you studied in university?
Or when you went to school, what level was that that you started taking program courses?
I'm talking here about later in high school, the AP or the advanced placement track at the time was in a language called Pascal, which by now has kind of, you know, fallen away into history.
But in the course of taking this AP test, I learned this dead language.
And the following year, they switched it over to C++.
So I retook the course again, still in high school, and learned C++ in the process.
And then, yeah, in university, I actually went a kind of different direction and studied cognitive science.
But it still has a foundation in a knowledge of certain computer science principles.
But that's a pretty different beast.
It is pretty different.
Although my experience with cognitive scientists is a lot of them have some reasonable programming skills to do their modeling and whatnot with.
Yeah, that's been my experience, too.
Yeah, cool.
So basic, Pascal, C++, how'd you get to Python?
I took a very long pit stop in the Pearl universe.
After university, I got pretty involved with building web applications and CGI.
This was, you know, the early 2000s.
CGI was the way to do it.
And Apache had a strong connection to the PHP community and to the Pearl community.
And I dug really deep with Pearl for years, but found that this was Pearl 5, 5.8, thereabouts.
And it really didn't have a good object model.
It didn't have inheritance.
And a lot of the things that I came to like from statically typed languages, such as, you know, C and Java.
And I found that I wasn't able to scale up Pearl web applications as large as I wanted to.
Eventually, the chaos just took over and the bit rot.
And I watched a number of software projects die in my hands.
You know, I loved them so much, but I just couldn't speak to them anymore because my own Pearl was just so backwards.
And anyway, I went looking for something that would be an interpreted language, but also provide strong concepts about object orientedness and inheritance.
And Python was perfect.
And it also had the momentum, the community of the Python, all the extensions and everything.
Then the decent documentation made it pretty easy to get started.
So I was really attracted because I just needed to make bigger applications.
And Python just perfectly filled that space.
Right.
Just better structure, better packaging, better ability to separate concerns, all sorts of stuff, right?
Exactly.
Yeah.
And I mean, you could do it in Pearl.
There was just an awful lot of ritual, literally ritual involved in that stuff.
And they just thought through it the right way in Python.
I love it.
Yeah, I think that's really important.
Because a lot of people, when they're comparing languages, they're like, well, I can do this in this language.
Or I could do that in that language or whatever.
And it's not always about whether it's possible to be done.
It's also how much is that part of the idioms of the language?
How hard?
How do you have to fight the thing?
Yeah.
Or do you?
Yeah.
There's a saying that I like, falling into the pit of success, right?
So if you design the language and the APIs, right?
If you just kind of follow the breadcrumbs, you end up in the right place versus the wrong place.
And I think there's a lot of that in the Python, the falling into the pit of success story.
So that's really nice.
Yeah.
Well, and you know, it's kind of like we, you have infinite power with Perl.
And it's the kind of thing where you need to stop and ask yourself if you should, you know, like in the first place, do you embrace that?
And the people who do become actual wizards and power maybe, well, I don't know.
Perl is really powerful.
Let's just say that.
Yeah, absolutely.
I've actually, yes, just following good Python practices like PEP 8, for example, or the Google style guides are great ways to accidentally write better code.
I mean, not accidentally, but just due to habit, create code that is so much more valuable.
Yeah, yeah, totally agree.
Totally agree.
So how'd you get interested in the combination of Django and Flask?
Like you were obviously doing CGI and Apache stuff with Perl before.
So you're already in the web space.
Definitely.
And I learned Django first because the documentation is so fantastic.
They have covered the novice, like the tutorials for the beginners.
They've covered all the depth that you would ever need in terms of API documentation.
It was just such a great example of how to build a really vibrant community that is able to get up to speed and then live with it for a long time.
So I learned Django.
I really like it.
I thought an awful lot about the model view controller pattern because that generalizes across a whole bunch of different frameworks.
But what I came to the friction point that I found was the typical object relational mapper.
The Django way of doing it is part of the core library.
And I was really attracted to SQLAlchemy just as a good single concern library that just solved the problems with SQL for all time.
And so I didn't want to sacrifice the clarity of using an ORM like SQLAlchemy just so that I could have a better web application experience.
I just didn't want my object relational mapper to be so tightly tied to my web stack.
And so Flask really provided a model that separated those concerns a lot more cleanly.
And when I say Flask, I'm also just kind of lumping in the Flask SQLAlchemy extension, which bridges it in a very natural way.
So for me, the ability to deal with the database and alone just in terms of SQLAlchemy and set aside the web concerns for a time meant that it would be a powerful enough way of expressing some really strong statements about the data.
I have a lot to say about the data.
But as I got deeper into scientific computing, that's where my concerns really lay.
And I couldn't imagine using Django to perform that kind of work.
I definitely don't want to give the impression you can't do these things with Django because I know that you very much can customize it and set it up just the way you want.
But I think it also goes a little bit back to that pit of success, right?
That's not the first thing that it encourages.
It doesn't say bring your own ORM and use it however you want.
Bring your own ACP client and do whatever you want with it, right?
It's more about these are the building blocks and you build with them.
Whereas with Flask or Pyramid, it's like you go through and you pick the type of thing you want to work with, the pieces you want to use across the whole 96,000 packages.
And then you put them together however you feel like.
And that doesn't work for everyone.
But it sounds like it works for you.
And that's also the way that I like to work.
So I think it's an interesting option.
Well, you know, it did and it didn't work for me.
I actually started running into trouble with taking Flask and then having the freedom, having the power.
Again, sort of thinking about Pearl and wizardry.
The ability to glue together absolutely anything that you can imagine can lead you into chaotic projects.
I think it's a lot of places where you do things in an idiosyncratic way and suddenly you can't really collaborate about your project anymore because you've done things because Flask let you.
I mean, I'm not blaming Flask, but it just requires such discipline to use it in a way that's predictable enough that any teammate could actually, you know, meet you halfway, read your source code, extend it.
I'm being a little bit hyperbolic here because I know that there are people out there that are being very successful using Flask in a team context.
But I found that I was getting burned by some of the power and I wanted to regularize some of the ways that I was using Flask and make some of those things repeatable, if only because I didn't want to have to start from scratch every single time.
As freeing as that is, I just didn't want to do that anymore.
Yeah, I do find a lot of times if you've been working in one company or one environment for a long time, you do feel like you're doing the same thing over and over and over again.
One company I worked at, I went so far as to build like a new app generator.
And it would spit out a new app with logging already set up.
We'd have like exception handling services, kind of things like Rollbar before they existed.
It would automatically, you know, all that stuff was integrated and you press the button and then you added, you know, where you went from there.
Exactly.
That is really handy as long as you can tweak and do whatever you want, I suppose.
Well, so yeah, that's a whole other can of worms there.
Because I kind of think that scaffolds, so there's a whole ecosystem now of Flask scaffolds because the idea of an app generator is actually really attractive.
A lot of people have gained efficiencies by automating some of that stuff.
And I went down that path.
I started using a Python library called Mr. Bob that just takes a template and a Jinja type template and spits out a file structure, like a directory hierarchy with auto-generated code.
And what I wanted there then was the ability to keep the app generator alive such that I could then fold back things that I learned in the process of the previous app into the scaffold so that the scaffold evolved along with my other projects.
And so actually that's a large part of Flask Diamond is that it is an app generator.
It will scaffold an application, maybe kind of like what you were just describing, you know.
It has logging already embedded.
Well, anyway.
Yeah, so tell us about your project.
I mean, I think we've sort of found our way to your project in this whole conversation.
So the thing that you created is called Flask Diamond.
What is that?
So Flask Diamond is, I see it as consisting of a couple of important components.
So at a high level, Flask Diamond is a batteries-included Python Flask framework.
So the batteries-included part means it will do something without you really doing anything at all.
So if you pip install Flask Diamond and then you scaffold an app, the app that comes out already works.
And everything's in it.
So it does have logging enabled and it does have all these features.
And, you know, some of these things I might describe a little bit more later.
But the batteries included means the Flask extensions are already there and they've already been hooked up in a way that basically makes sense.
For a typical case, this is the kind of thing that's impossible to anticipate everybody's individual project considerations.
So you want to get kind of a happy medium between providing something that actually does something kind of neat without any configuration.
And it doesn't ideally have too much bloat in terms of getting in the way of you configuring it for however your project is going to deviate from whatever the defaults are, whatever the opinions are.
Right.
The more opinionated you make it and the more features you add to it, kind of ironically almost, I suspect, means the fewer people who are interested and enjoy it.
Right.
Yes, I think so.
Because if you're like, oh, it needs logging.
Most people are like, yeah, logging is good.
Oh, it also needs like caching.
It also needs message queues.
It also needs like, whoa, I don't need all this stuff.
I'll just, you know, you start to push people out, right, as you like overdo it.
So, you know, how did you find that balance?
I don't know that I have just yet.
So I'll issue that disclaimer.
But I will say that for my own uses, I do think that it meets a certain balance by being, I'm calling it radically decomposable.
So what I mean by that is it is actually safe to strip away pretty much everything that comes sort of bundled by default with Flask Diamond and actually create a command line app that doesn't even use Flask to spin up a web server and a database model.
I've actually used the whole Flask Diamond setup to create, yeah, really simple little scripts.
But I've also used that basic pattern of a command line driver with a full-fledged SQLAlchemy database lurking behind it.
And again, I'll use Flask Diamond to do that because it merely simplifies the interfaces and the process and the extensions and importing the database models and setting up the namespaces in a predictable way.
You know, it does all of that for free such that I actually don't care if Flask happens to be a WSGI environment, you know, an HTTP server.
I'm actually using it as just this really general purpose application framework.
And I even consider the web part to be decomposable and extractable from the whole rest of the application platform.
So what I'm saying is I don't even always write web apps with Flask anymore.
There's a way of using the Flask application context to script an app that does not actually need to be running in conjunction with a WSGI server.
It's an incredibly powerful pattern.
And it's another thing that I would never do with a thing like Django.
That is, it's very heavy.
And when you start up a Django process, it's not that easy to slice out different pieces of the core.
But with Flask, pretty much nothing is included in the core to begin with.
Yeah, even Flask itself is made up of like a number of building blocks that are put together, like It's Dangerous and Vexig and those sorts of things, right?
That's right.
You know, you mentioned It's Dangerous.
And one of the things that is kind of nice about folding in something like It's Dangerous using something like Flask Diamond is that by default, it's just folded in in a way that is going to work.
So the pathway there is through Flask security and Flask security will sanitize all your inputs with It's Dangerous and perform all of the cross-site scripting protections.
And so, you know, it's there.
You know it's there and that your input will be sanitized.
And frankly, if you don't want it, you don't have to have it.
You can also get rid of all that.
This portion of Talk Python to me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Relying on users to report errors, digging through log files, trying to debug issues, or a million alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you'll get the context, insights, and control of the data.
All that you need to find and fix bugs faster.
It's easy to install.
You can start tracking production errors and deployments in eight minutes or even less.
Rollbar works with all the major languages and frameworks, including the Python ones such as Django, Flask, Pyramid, as well as Ruby, JavaScript, Node, iOS, and Android.
You can integrate Rollbar into your existing workflow.
Send error alerts to Slack or HipChat.
Or even automatically create issues in Jira, Pivotal Tracker, and a whole bunch more.
Rollbar has put together a special offer for Talk Python to me listeners.
Visit rollbar.com slash Talk Python to me.
Sign up and get the bootstrap plan free for 90 days.
That's 300,000 errors tracked all for free.
But hey, just between you and me, I really hope you don't encounter that many errors.
Loved by developers at awesome companies like Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch, and more.
Give Rollbar a try today.
Go to rollbar.com slash Talk Python to me.
Before we get to the nitty-gritty details of it, tell me why and when did you create this?
How old is this project?
And what got you to say, all right, I'm making this thing?
Totally.
So this has been going on for years by this point.
And it's the kind of thing that didn't happen intentionally.
No one ever sits down and says, I'm going to write a framework today.
But I needed it.
I found that I just needed something to fill a missing spot in my research pipeline.
Pipeline, basically.
So I was doing a lot of work with online memes and their propagation through social networks.
And so I was building a couple of web apps.
And I guess this is 2011, 2012.
I was using a framework called WebPy, which Reddit was using.
And at the time, the principal author was a guy named Aaron Swartz, who died in early 2013.
And the WebPy project died with him, as far as I can tell.
So I needed something.
Yeah.
That whole story is super tragic.
Yeah.
It's unfortunate.
Yeah.
It's very sad.
Yeah.
It's interesting to consider some of just the rippling costs, the things that a huge tragedy,
actually.
And so when you're trying to do some kind of academic work that's going to be reproducible,
be repeatable, the code needs to be shareable.
It needs to be portable.
You need to be able to give it to other people and they need to be able to run it.
And it also needs to be able to run ideally 5, 10, 20 years in the future.
And so a web framework that's not going to be evolving beyond 2012 or so is no good.
So I experimented with Bottle and I liked it.
And just I discovered Flask.
It's kind of, I think, because of the plan words between Bottle and Flask.
And in summer of 2013, I started really making some of these ideas into a repeatable template.
So I was building, at this time, an application to model Twitter.
I was scraping a ton of Twitter data.
And so I had all these different types of objects.
There were accounts and there were tweets and there were links between them and all the
data model that you need to do to scrape Twitter.
What I really needed was a way for other peers, collaborators to be able to look at this data
without needing to understand SQL themselves, without needing to understand Python, ideally
without even me needing to be there.
And it was through Flask that I discovered this whole ecosystem then of things like Flask
Flask admin and Flask security and the whole rest of it that I started assembling into this kind
of research data support infrastructure.
So all my data then I could put on a server somewhere in the cloud and just give a login to
an advisor and they would be able to look at it.
So the need was really, I just had so much data and I wanted to talk about it.
I wanted to collaborate with it.
And like I said earlier, I didn't want to have, I didn't want to be tied to the Django ORM.
I just wanted to use SQLAlchemy.
Cool.
I think that's a really forward looking way of doing it.
Here, I'm doing this research.
I'm going to put it on the web.
You can just execute it, slice it, dice it, whatever you want.
This predates Docker, but it seems to me like Docker is being used by a lot of scientists
for that purpose as well.
Like I'm going to package up the execution of my analysis into a Docker image and then you
can go do what you want.
So it's like the next level or something.
Yes, absolutely.
A kind of anecdotal story is that back in the day, I was aware of a guy in this one department
who needed, for timing purposes, he needed these 286s because that was the only thing that would
execute his code at the right timing for a certain kind of reaction time task that he was recording.
So he actually stockpiled these 286s.
And I mean, by the way, this was happening in like 2008.
So someone with a big pile of 286s, all for the purpose of getting the software to run exactly
right decades after it was originally written.
It's a serious problem.
It really is.
You take the 286, 16 megahertz and don't press the turbo button or it won't work right.
Exactly.
That'll screw up all your data.
Yeah.
But no, I mean, it's a real problem.
And reproducibility is a big it's a hot topic in science right now, especially in the field
of social psychology, which is kind of my home base right now.
These issues of sharing data between labs and getting the same results, even when different
researchers do it.
It's actually getting a lot of cool papers written right now.
So anyway, yeah, it's really important for data to be kind of social.
Sure.
I don't think that we as an industry or users or programmers across the board, we're not
used to thinking of execution as a thing that has to be kept for long terms of period.
We think about how are you going to archive data?
How are you going to make that interoperable so you can read it in the future?
But not like, how am I going to be able to run this algorithm that nobody's going to rewrite
or something like this?
This is an interesting problem.
It's not something that affected my day to day life until relatively recently.
But it gives me new respect for mainframe type stuff, like the whole IBM system 360 stack
that goes back 50 years and what they have done to virtualize hardware and enable code, ancient
code to still execute today.
I mean, I think about just the horrors that the banks must be facing on a regular basis.
So yeah, you know, let's be sensitive to those forward looking issues.
And I don't know, maybe mitigate that a little bit.
Fully the solution.
But anyway.
Yeah, it's a small deposit.
But I think you're probably right that like emulation and virtualization and, you know,
throw containers in there.
Those will like alleviate that to some degree.
But still, it's going to be tough.
So there's a bunch of cool features to flash diamond.
Let's let's dig into those for a bit.
Yeah.
So what I found was, you know, when we're talking about not wanting to repeat the same
steps every single time you start a new application, I found there were a couple of features that
pretty much every application I needed to build, it required those features.
And I've already talked about some of these things that I just needed in the process of
just normal, like I say, social data, like collaborative access to my data.
And so this account management is a pretty obvious feature.
It is provided by Flask admin in association with a number of other really helpful extensions.
So I've already mentioned Flask security.
And one of the things that I actually liked a lot about Django is the way that you get this
GUI management interface kind of for free.
Whatever your object model is, Django makes it so easy to get in there, see it in your web browser,
create test data.
And so that's something that Flask admin provides pretty easily.
And so I really wanted to bake that in.
So administrative access just works.
And then databases are especially important for me.
I've used a whole bunch of different SQL backends, but I've also used MongoDB very successfully
with Flask.
This is another instance where just because Flask diamond has a little opinion about databases
and the basic entity relationship pattern for describing object models, despite that, it's
really not very hard to switch that out for Mongo.
And when I say not very hard, I mean five lines of code.
There's no extremely deep epistemological commitment to using a SQL database just because the default
is a SQL database.
That's cool.
And so you have a SQLAlchemy part of that story?
In a couple of different ways, actually.
So SQLAlchemy is not the only object relational mapper, but it has documentation that is spiritual.
I think alchemy is a great term for what SQLAlchemy does.
They go to crazy places in terms of what they are doing to layer the SQLAlchemy core on top of these
relatively stupid databases.
I'm just so impressed with what SQLAlchemy has done.
Yeah, I really like it too.
I use it a lot.
Yeah.
But, you know, there's other ones like PeeWee that are really popular and a lot of people like it.
In terms of being opinionated, you know, in terms of offering these little opinions for optimizations,
the reason that I'm going with SQLAlchemy is because sometimes there's just a really crazy thing that you just want to do.
And they've already thought about it.
I haven't found something that I can't do yet with SQLAlchemy.
And if there is something that maybe you can't express with SQLAlchemy, you can always just drop to a database shell and do it directly in Postgres or whatever.
So that's another thing that I never wanted to get too far away from was the ability to just physically interact with the database and not lose some connection back to the original web application.
And like I say again, the alchemy is magic.
Nice.
What they have done makes it possible.
Yeah, it is really great.
I think it never ceases to amaze me that you really can keep on doing that.
I can also model that and see what I mean, right?
Yeah, basically, I think it's good enough for real research.
Yeah, I totally agree.
I guess that's the story.
Yeah.
Yeah, and there's a lot of interesting places using it in production.
I forget some, I don't want to say the wrong one off the top of my head, but some really major apps that are very cool, major companies using it.
You also talked about pointing Flask Diamond at existing databases and having presumably the SQLAlchemy classes, the models generated from existing databases.
Tell us about that because that sounds like saving a ton of work.
This is actually just some kind of experimentation that I've done on the side with some of my buddies.
And we have done it successfully.
SQLAlchemy ships with, it's a Python script that'll scrape your SQL schema and auto generate model code for you.
So I don't want to give you the wrong idea that this is already baked into Flask Diamond.
Simply that we have done it in a Flask Diamond app.
It worked pretty much.
And it did save us time in this one instance.
So I mean, again, this is kind of like sort of spooky, pseudo-magical stuff here.
And I'm saying like, yes, yes, this is possible, but I will only speak of it.
I won't actually show you.
But you'll just have to take my word for it.
But it's possible.
Yeah, I've done that before as well.
I think there was a third-party package that didn't come directly from SQLAlchemy.
That sounds right.
Maybe the contrib.
Yeah, it might have been contrib or something that was like, hey, this works with SQLAlchemy and it'll like read your schema and it'll actually generate your classes.
And maybe the classes have stupid names and you need to go edit them a little bit.
But still, like when you're looking at a big daunting database and you're like, oh, I got to get started with this.
Like the ability to auto-generate or pre-generate like a starting place is really cool.
Yeah.
And it worked.
Yeah, like I say, it worked most of the way.
Which saves you most of the work.
That's right.
Yeah.
That's awesome.
You said it also has one of the features is model CRUD.
Create, read, update, delete.
Yeah, that's right.
Create, read, update, delete is a really useful pattern that I've encountered all over the place.
And all the more so with RESTful HTTP interfaces where the basic HTTP verbs more or less map on to create, read, update, and delete.
And so I just found that I was doing this constantly.
And so I wanted to do this.
And so I wanted to persist that through just the general object model.
And so this is actually implemented as a mix in that you can include with any SQLAlchemy object that you create.
And it simply extends your model with create, read, update, and delete for free.
And it extends it a little bit more with the ability to rapidly load and dump objects from JSON.
Or you can extend it further for something like CSV.
So the idea is to take some of the nice stuff from the GUI CRUD and enable that Pythonically.
It's just a convenience thing, but I use it constantly.
It's really the only way that I'm interacting with objects anymore is through this CRUD interface.
Huge time saver for me, at least.
Yeah, that sounds cool.
Another thing a lot of apps need is email.
Definitely.
It's a necessary evil.
Email is kind of an out-of-channel or an out-of-band way of communicating things like account changes.
And actually, Flask security provides a number of features for email account confirmation if you're going to incorporate some kind of second factor authentication into your platform.
So email is a necessary thing.
It's provided by Flask mail.
Again, needs to be integrated.
And once again, Flask Diamond gives you an integrated email solution for free, batteries included.
However, in this case, this is the kind of thing that not everybody needs.
And so I've gone the extra step and I've actually commented out the one line that would enable email by default.
And so if you find that you actually want it in your app, you are going to have to uncomment that line.
But then, you know, emails is just there and it's free.
And it works.
Yeah, that's really great.
And testing.
One of the things I feel like is more possible, things like Flask, the micro frameworks, is because they're just less, they're easier to test.
Yeah, it's possible to get in there and test some really low level things like the generation of signals or like I mentioned the application context earlier.
The ability to create an application completely separate from any kind of web server or any kind of WSGI serving infrastructure is so powerful for testing.
And so Flask testing makes some of these things really easy, like creating a debugging server and creating a phony HTTP test client for local testing of HTTP interfaces.
So, of course, that's stitched in.
But also, a simple testing framework is included with the scaffold to provide some examples of how you might use nose test, which is one of the Python testing suites.
Other examples are pytest or Tox.
And, you know, once again, you can actually use another testing platform, apart from nose, relatively easily.
So I actually use Tox on a couple of projects.
But the scaffold includes some, a pattern for building a test harness using nose tests and integrating it with the command line, making it pretty easy to run single tests, to run all of the tests, to automatically run tests when a file changes.
Certain things that become really more like the DevOps side of things.
Once again, a basic workable solution comes for free out of the box with Flask Diamond.
And once again, it's the kind of thing that if you don't like it, you can just delete it and it's gone because it's really not baked in very deeply.
It's just hooked in enough that it'll work, that the make file has a make test command and it'll do the right thing unless you don't want it to.
Right.
There's probably like a test stop py or something like that.
Exactly.
Hang around somewhere.
Yeah.
It was a test directory, but anyway.
Right.
Okay, sure.
You could delete the test directory and you're done with the test if you don't want it or whatever.
Yeah.
This portion of Talk Python is brought to you by Hired.
Hired is the platform for top Python developer jobs.
Create your profile and instantly get access to 3,500 companies who will work to compete with you.
Take it from one of Hired's users who recently got a job and said,
I had my first offer on Thursday after going live on Monday and I ended up getting eight offers in total.
I've worked with recruiters in the past, but they've always been pretty hit and miss.
I tried LinkedIn, but I found Hired to be the best.
I really like knowing the salary up front.
Privacy was also a huge seller for me.
Sounds awesome, doesn't it?
Well, wait until you hear about the sign-in bonus.
Everyone who accepts a job from Hired gets $1,000 sign-in bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the signing bonus to $2,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the door.
You also talked about deployment.
How's the deployment different or enhanced with Plast Diamond?
I came to really like a Python package called Fabric that abstracted away some of the weirdness of SSH and RSync and simplified some of the management of remote tasks that occur on your testing server or on your production server.
And so I started baking this into the scaffold again.
So what comes for free is a little fab file that actually I want to take a step back.
For deployment, you can do it in a couple of different patterns.
There's a way in which you could push your code to a central Git server or something like that and have all of your testing machines automatically pull from that server or have your production machines pull from that server.
And so that's kind of a passive deployment.
And then there's also an active deployment where you physically push the code to the machine that you're actually going to be running it on.
You know, you don't relay it through some other intermediary server.
And so I wanted to support both styles, actually, of deployment.
And so that's supported with Fabric and with a command line interface, because this is the kind of thing that every command is a one off.
And you just want to rapidly be able to SSH to a deployment server or push the code directly to a deployment server.
And these things happen constantly.
I just wanted, again, a simple solution that came for free out of the box.
Yeah, that's cool.
So nice that that's built in there.
So another thing when I was cruising around your website that I saw, you were talking about facets.
What are facets in this project?
In a roundabout way, I've kind of been describing what these facets are.
A facet is kind of a feature.
So, you know, a facet is kind of like a face of a surface or as a play on words, a diamond is faceted with many faces.
And so each of these features is actually a facet.
So there's an account facet.
There's an administration facet.
There's a databases facet.
There's an email facet and so on.
And the basic idea is that together, these facets are the default types of considerations, the typical considerations that many of these web applications just require.
You know, insofar as many of them need accounts and administration.
Well, those are facets.
At the Python level, each facet is really like a proxy for the extensions that are loaded to actually provide that facet.
So I mentioned that Flask admin and Flask security have an interplay where admin uses security for login purposes.
And the facets just ensure that those get that all the objects are created in the correct order and that Flask security knows about Flask admin.
And what this means, again, Pythonically, is that you can either inherit and override or completely comment out any of these facets and really control whether or not your application has that facet at all.
Right. Or replace it with something different.
Exactly.
Yeah. OK.
And so it creates like a predictable hook where if you're going to use a different database, then that's where you do it.
You know, you don't just randomly decide when you're sitting down to create the application that, you know, I'm going to do my database, whatever.
This is predictable place where all the database stuff happens.
You just go to the database facet.
And if you're going to use Mongo, then you do it there.
You just override, you inherit and override what I wrote.
And boom, that's the right place or the opinionated place.
Certainly not the right place, but that's the agreed upon place.
Sure.
I see.
So it's kind of a convention.
The facets sort of bundled, like your convention on top of like Flask security or some part of the API.
Exactly.
Convention is a good word for it.
It's creating some conventions.
OK.
Conventions are good.
That's cool.
So let's assume that people out there are basically familiar with how you write Flask apps and how you write Django apps.
Can you talk just a little bit about like, what does it look like?
What's the API look like?
Does it look a lot like Flask?
Does it look like Django?
Like what do I, what are the feelings I get when I write code in this, on top of this?
Totally.
I would expect it to be really familiar for Flask users.
Because what comes out is actually a Flask application.
The process starts off a lot like Django.
You know, I was saying that Django has done such a great job of creating tutorials and making it easy for new users to get started.
So just like Django, Flask Diamond begins with a scaffold and it creates a directory structure that would be really familiar to somebody who uses Django.
So there's a manage.py and it does basically what you would expect.
You can do manage.py server and then it'll, you know, just run your server or manage.py DB.
And it gives you access to all of your database stuff.
So in that sense, it's reminiscent of Django.
And incidentally, all of that manage.py stuff is implemented with Flask script, another really great extension.
But after you scaffold your application, it really comes to resemble Flask.
The basic pattern uses the Flask create app idiom where somewhere in your project code, instead of just directly instantiating all of the Flask objects, you wrap that in a function called create app.
And that really simplifies testing and it does all these things.
And that's kind of the Flask way to do it.
And all the extensions have an init app style of object creation.
So Flask admin, it has a slightly opinionated way of setting it up.
So once you have your application scaffold, it follows all the Flask conventions.
You'll find a create app is inside your init file.
And you'll find that each extension is created using the typical Flask init app idiom.
I would expect that everything else should just look pretty much like another Flask scaffold.
Okay.
You might find online.
Yeah, cool.
So maybe not like a new Flask app, but like more, a more mature one you've dropped into or something.
Yeah.
Okay.
You talked about the Django tutorials and documentation and they are really important.
They make a big difference.
Actually, when the Django tutorial switched from just by default recommending Python 3 over Python 2,
that made a significantly measurable difference in Python 3 usage on PyPI.
Yeah.
So, you know, that I think speaks pretty strongly how powerful the Django documentation is.
But yours is really nice as well.
And you have a tutorial called Planet Tutorial, which I thought was cool.
And it has a video as well as like a screencast video as well as just the steps, which I really like that.
Yeah, thanks.
Like I say, I'm really inspired by Django and what they have done.
And one of the things that I've put a lot of time into over the years, because this is several years in the making,
is creating some kind of a compelling story or a tutorial that kind of made sense at some level.
And so I used to use an example about chess.
And, you know, there's a board and there's pieces and there's players.
And for some reason it didn't, I don't know, I guess I didn't care at a certain point.
Like it wasn't interesting implementing chess.
And I had a breakthrough a couple of months ago when I realized that whatever tutorial I write about,
it really needs to ship with working code.
The two need to play off of each other.
So over the course of a couple of weeks, these ideas kind of came together.
And the planets tutorial actually ships as another code scaffold.
There's only two that ship with Flask Diamond.
The one will create an application for you.
And the other will set up this planets tutorial.
And so it's working code that comes in the package and it maps on to the documentation.
So the idea is it should be a consistent story.
Part of why that's important is to make it possible.
So let's assume that you're doing some team collaboration, some development that involves a couple of people.
And let's assume that they know Python and maybe even they know Flask already.
The idea is you should be able to point them at something and make it pretty easy for people to become initiated or get up to speed such that they can collaborate.
So the planets tutorial is really just there's planets and there's moons or there's satellites.
And it walks through creating Earth and Mars and Venus and just adding a couple of moons around those planets.
And at that level, it's actually pretty pedestrian.
There's some simple models.
But I just kind of liked the story a little bit more than, I don't know.
It sounds intriguing.
Like I want to go through a planets tutorial.
Yeah.
Well, hey, it's an 11 minute video.
So nice.
How about how are you using this?
You said you're using this in a few interesting ways in production today, right?
Yeah.
So I am actually using it in production.
And I gave a few examples of some research projects where I wanted advisors or peers to have access to this stuff.
But I've done a couple of other projects more recently that are actually live and out there and even potentially getting some decent traffic.
So peopleapi.com.
So that's P-P-L-A-P-I dot com is something I've been working on for a couple of years.
It's part of my dissertation work.
It's a virtual database of the human population.
So for everyone who is alive, approximately in 2014, that was about 7.2 billion people.
There's an entry in this database for everybody.
Now, to be clear, it's synthetic data that's not actually scraped from Facebook or something like that.
I have a bunch of algorithms based on demographics that make guesses about where everybody is and how old they are and all that stuff.
And, you know, and the guesses are pretty good.
But the idea is that they're not real people just yet.
But it's billions.
I mean, it's a really big database.
That is a big database.
Yeah, something like seven terabytes.
And I was really happy that this got featured on Hacker News and Product Hunt last week.
And the website did not fall over.
I was sustaining 150 simultaneous connections.
And it held up on a virtual machine in the Digital Ocean cloud.
So that was actually a pretty cool validation of the ability of one of these applications to sustain moderate traffic.
And it's also a demonstration of the ability to manage a pretty sizable database using SQLAlchemy and exposing that over the web and coping with some kind of scale, coping with, like I say, a little, like a moderate amount of traffic.
So I'm pretty happy about that.
PPL API dot com.
But another thing that I'm doing that kind of relates to me as an open source developer is that I've been looking at GitHub.
And they have a ton of data available through their API.
And there are actually a bunch of academics out there who are scraping GitHub.
There's a lot of interesting research you can do with that data.
So I have created an analysis called GH Impact.
This relates to the number of projects that have a certain number of stars or more.
So if you have 10 projects with at least 10 stars, then you have a GH Impact score of 10.
And if you have 100 projects, each with 100 stars or more, then you have a score of 100.
And only companies like Google and Microsoft and Mozilla are able to get these scores that are really high, to have 100 projects.
And every single one of those projects is well liked on GitHub.
And typically, even prolific developers have fewer projects and they get fewer stars.
Or if they have one popular project, then they probably don't have a second popular project.
So this is kind of a social analysis of the impact that people are able to achieve through a platform like GitHub.
Once again, this is live on the Internet.
And once again, I did all the data modeling with Flask Diamond.
And in this case, one of the ways that that was really useful was the ability to extract small amounts of data from this, you know, this like 150 gigabyte database through a REST API.
And so that enabled me to use a statistical package called R to not have to load the whole 150 gigabyte database.
I was able to use a little tiny bit of data through the REST interface that I built.
In that manner, I was able to fit my analysis in RAM.
Because R is just not powerful enough to deal with an enormous database of many gigabytes.
And so for certain analyses, a tool like Flask Diamond fills a really crucial data translation role of adapting huge data down to relatively underpowered statistical workstations.
Yeah, that's cool.
So is it kind of like, did you kind of like sample or poll the GitHub population and then compare name you put in there against that?
No, I got all of it with like certain caveats.
I scraped as much as these other researchers over in the Netherlands have scraped.
Their project is called GH Torrent.
The torrent thing is, I think, irrelevant.
Now I'm pretty sure it's just a distributed scraping project.
As much as they were able to scrape, which is, I think, you know, certainly more than 90% of GitHub.
Yeah, that should be statistically relevant.
Yeah.
Yeah, yeah.
I got all of it.
So, no, I didn't sample any of it.
I just extracted specific columns and subsetted the data so that I was able to fit only what I cared about into RAM and ignore the rest.
Nice.
So I had to type my name into it because it's the only one I knew off the top of my head.
I have a GitHub impact score of eight and a 99 percentile.
Yeah, yeah.
That's cool.
It ceilings out pretty rapidly.
And, you know, so, you know, your score might be a little bit higher than that because, like I say, maybe they haven't scraped the whole thing just yet.
But, yeah, what that means is you have at least eight projects with each eight stars or more.
In all likelihood, some of those projects have way more than eight stars.
But the way that it draws the line is I guess they're not nine projects each with at least nine stars.
Yeah, that sounds right to me, actually.
It's pretty cool.
It's a cool measurement.
Yeah, thanks.
Yeah.
They like it in academia.
So, anyway.
Yeah, very nice.
So, the last one that you want to talk about in production is GThink.
This one's a weird one.
Without the I.
G-T-H-N-K dot com.
Yeah.
So, I do pronounce it GThink.
So, you got that right.
It's not actually hosted remotely.
This is one that you download and then you run it locally.
And on OS X, GThink installs as a launch service.
So, it's just kind of always running in the background.
And it's a note-taking application of sorts.
It's not in the cloud.
You know, it's not hosted remotely, which is, I believe, a security feature.
Like, I really don't trust a hosted cloud service to store my personal notes.
I would much rather just have a program running on my own computer.
That's what GThink is.
It's like a self-hosted Evernote or something along those lines.
Okay, cool.
It demonstrates that Flash Diamond can be packaged in a couple of different ways.
Not only hosted online.
That is really cool to have it as a desktop app.
Okay, nice.
That's quite an interesting twist.
So, tell me the story of Python 2 versus Python 3 with your project.
Yeah.
This was a bit of a struggle, actually.
Because the ecosystem was a real barrier.
Insofar as all the packages that Flash Diamond relies upon, they all need to have made the switch to Python 3.
And by now they have.
But also, you know, there was a little bit of stuff inside Flash Diamond itself that needed to be updated.
I eventually made the leap within the last year.
But I think I found that Travis, actually, in automated testing, is a real asset with Python 2 and Python 3 compatibility.
So, the ability to automatically run the test suite with different Python interpreters has saved me a lot of headaches.
Because I'm catching a lot of bugs that, well, less now the transition has been made.
But it caught an awful lot of bugs moving from 2 to 3.
But I find now that I make all my new projects using Python 3.
And personally, I'm really enjoying what's happened with Python 3.
And I do kind of, I check in on the arguments whenever it comes up.
You know, why isn't Python 3 whatever?
I like to sort of torture myself reading that stuff online.
Because I was held back for quite a while on Python 2.7.
Now that I have made the switch, there's no going back.
Yeah.
I really do like that.
Yeah, I'm with you.
There's a whole bunch of cool stuff.
Especially around concurrency and async stuff.
And just a lot of polish on the language.
Yeah.
Strings and bytes and Unicode.
It's so much better.
I feel like we, as a community, have sort of turned the corner.
A year ago, a few years, it wasn't entirely clear that Python 3 was like,
of course you should be doing it.
People were still like, no, I don't know about this.
I feel like most people, even though maybe they have a project that's not quite converted
or they don't foresee themselves able to move whatever project to Python 3,
like the recognition that it is the way to go, I think is definitely growing.
So I think it's a pretty positive move.
Yeah.
I think finally the critical mass is there.
Yeah.
And it's the way forward, clearly.
Absolutely.
All right.
Well, your project looks really cool.
I feel like, you know, we've got Flask at one end with the micro frameworks.
We've got Django at the other end.
It's more sort of full-featured building blocks.
I talked with Julia Ellman and Mark Levin on episode 88 about a lightweight Django and bringing,
you know, sort of unrolling some of the stuff out of Django to make more lightweight,
to bend it however you want.
And this is kind of taking some of the niceties of Django, put it in a flask, and you're kind
of like filling out the spectrum.
I hope so.
Yeah.
So it sounds, I think it's a cool contribution.
Yeah.
Thanks.
Yeah.
So let's see, before we go, let me ask you the two final questions.
If you're going to write some Python code, what editor do you use?
It's Sublime Text 3 these days.
It's Python all the way down.
I love Emacs.
I love the Emacs philosophy.
And I love Lisp.
But the idea of redoing Emacs with Python as its heart and its brain is too cool.
So it's Sublime Text.
Yeah.
That's pretty cool.
Have you seen the Anaconda plugin for it?
I have not.
It's not the same as the Anaconda distribution.
I think these things are unrelated.
But it's like an extension for Sublime that brings all sorts of Python features, apparently.
I just ran across it recently.
But I haven't really explored it.
Yeah.
I would have just discounted it as just packaging of the other Anaconda.
Well, that's awesome, actually.
I'm going to check it out.
Yeah.
I'm quite sure that it's a different sort of thing.
Cool.
Yeah.
Cool.
So I'll put a link.
Yeah.
So here it says, I open it up and it says, Anaconda, the Sublime Text 3 Python IDE.
And it gives you all sorts of functionality.
Yeah.
So it's not the same thing as the Anaconda.
It's a different thing.
Check it out.
I'm giving that a look.
Yeah.
Awesome.
Okay.
And then there's over 96,000 PyPI packages.
I can't wait till it gets to 100,000.
There's got to be some kind of celebration.
But why don't you tell people about some that you think are cool they should know about.
Check out.
All right.
So I've already said so many good things about Flask and Sequel Alchemy.
Together, they have changed my life, I think, probably for the better.
So everybody needs to go look at those two.
But I also just want to, there's a special place in my heart for Beautiful Soup.
It's a throwback to an earlier time.
But when Beautiful Soup came along and made it easy for me to parse even really broken and terrible HTML,
and actually I was able to start doing useful stuff with web scraping,
and I began sort of collecting some data that I was unable to access before.
I think there's a way that Beautiful Soup might have improved my life more than anything else in PyPI.
That's really cool.
It's a special place in my heart for that one.
Yeah.
You talked about the alchemy.
The alchemy nature of Sequel Alchemy.
Beautiful Soup is kind of magical as well.
Yeah.
Everything becomes an API even if it's not supposed to be.
Right.
Awesome.
And it's surprisingly easy to use.
So if you guys need to do web scraping, check it out.
It's definitely cool.
I can recommend it as well.
All right.
How about a final call to action?
You looking for contributors to this project, people to try it out?
Yeah.
Definitely check out the website flask-diamond.org.
That'll link you through to GitHub.
I'm looking for people to battle test this on Windows because that's harder for me to do.
And ideally give me feedback.
Or even better would actually be some edits to the documentation because I want to break down the barriers to get some new users initiated into this flask ecosystem.
Yeah.
That sounds great.
You know, people are always asking me like how they can contribute to open source.
Like something that just came to mind is maybe they could come write a tutorial and you could have like a whole bunch of tutorials.
Right.
That'd be a fun way to like a fun and easy way to get started.
Right.
I would love that.
And, you know, make a screencast video.
And man, you're you're you'll be my friend for life.
That's awesome.
All right.
Well, this is a really cool project.
And I think it's, you know, fills an interesting space in the spectrum of the web and Python.
So thanks for building it.
And thanks for taking the time to share the story.
Thanks.
It was really my pleasure.
You bet.
Bye.
This episode's guest has been Ian Dennis Miller.
And the episode has been sponsored by Rollbar and Hired.
Thank you both for supporting the show.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to Me to get five or more offers with salary and equity presented right up front and a special listener signing bonus of $2,000.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart by Building 10 Apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/Pythonic.
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, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
Outro Music.
Bye.
.