It's time to obey the testing goat and fire up some Python in the browser.
This is Talk Python to Me, episode number 10, with guest Harry J.W. Percival, recorded
Tuesday, May 12, 2015.
Hello, and 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 talkpythontimmy.com.
This episode, we'll be talking to Harry Percival from Python Anywhere about hosting Python applications
and making Python available to the masses, as well as his book and mission, TDD in Python.
I'm thrilled to tell you that this episode is brought to you by Codeship.
Codeship is a platform for continuous integration and continuous delivery as a service.
I'll talk more about them later in the show.
Please take a moment to check them out at codeship.com or follow them on Twitter, where they're at Codeship.
This show is kind of special because I've traveled all the way from the west coast of the United
States to cheerio, London to meet with Harry in person.
Well, maybe I also came here for a conference in central London, which happens to be close to Python Anywhere's headquarters.
Either way, it was really fun to do an in-person interview with Harry.
Now, let's get to the show.
Harry, welcome to the show.
Hi, Michael.
Thanks for having me.
I'm excited about it.
This is really an amazing show.
It's the first one we're doing in person.
Right.
Okay.
All right.
Well, I hope I don't mess it up.
No, you definitely won't.
So I'm here in London.
I'm not normally in London.
I love this place, but I don't live here.
So it's kind of unique.
And I happen to be at a conference like a block away from your office where Python Anywhere is.
Right.
There you go.
And so why don't we get together and do this in person?
And here we are.
Fantastic.
All right.
So I really want to talk about Python Anywhere.
I want to talk about Obey the Testing Goat, all those types of things.
But let's just start at the beginning.
How did you get started in programming?
How did you get started in Python?
Sure.
I guess I started in programming when I was quite young, like a lot of people, maybe when
I was 10 years old, on various old bits of hardware from the, this is the sort of early
90s, maybe even the late 80s.
And I had like an Amstrad PCW green and black background, had like one of the early Olivetti
laptops.
And this thing had, it had not one, but two three and a half inch floppy drives.
Oh my gosh.
No hard disk at all.
And you could run, you could run MS-DOS on one and Microsoft Word or a really good copy
of Snake on another one.
And then at school we had them as well.
So I was programming in basic.
I had a few books from America.
And at school we had these things called Thompson TO7s.
I've never heard of that thing.
Yeah.
Okay.
So it's a, it's like a, it's a big ugly box thing that you plug into a television screen
and it's got these like rubber keys on and they go like boop when you press them.
You know, 10 going toot, doot, go to 20.
And we're programming basic.
And the cool thing with that actually was that they had, they had this thing called an input
pen, which was like this pen thing that you could press against the screen.
And it had some voodoo that then would be able to register an XY coordinate against where
it was on the TV screen.
I guess it was like calculating where the sort of raster had got to or something like that.
That's pretty cutting edge for it.
What year was this?
This is like 1992, I'm going to say.
Wow.
Right.
That predates Mozilla.
Well, I think those computers were already old then, to be fair.
And so, yeah, we would make like little drawing programs on them, which is really cool actually,
because if you watch kids programming these days on much more advanced computers,
they've got really cool things like Scratch.
They don't have to go through basic and go-tos.
But they did exactly.
I mean, you watch kids in schools doing this.
They do exactly what I did at that age, which as soon as you figure you can do some graphics
on the screen, you start making a paint program, you draw circles and squares and spirals and
things like this.
And so, yeah, yeah, that sort of thing.
I'm sure everyone's got a similar story.
That's awesome.
So that's basic.
How about Python?
Yeah.
So that was my origins, right?
I was on the right path.
And then somehow my life went wrong and I sort of went and studied economics and I got a job as a management consultant,
which was very tedious.
And I didn't really do any programming other than kind of overcomplicated Excel spreadsheets
until I was pretty much 30 years old.
And this is like 2008.
I took a sabbatical from my job, which turned out to be just me quitting, basically.
Go off and do a new degree and get a master's in computer science and just learn programming again
and kind of do it properly.
And then I went off and that's what I do now.
Nice.
Was it really refreshing to step away from science?
Yeah.
Well, management consulting is a lot of talk, not so much action.
Yeah.
I mean, so it's not for everyone, I think.
It wasn't for me.
And it was interesting in parts.
But I found myself, like, just if I looked at the part of the job that I enjoyed,
it was mostly just making an overcomplicated Excel spreadsheet and, you know,
like just a 25-line functions in Excel and, like, VBA to do things that were, like,
absolutely not required by the project that I thought were cool.
So, you know, there was a clear direction I should probably have been going.
You should have taken that clue.
You know, my programming experience is like that as well.
I kind of became an accidental programmer.
I was working on my PhD in math and was working on some Silicon Graphics,
like supercomputers, right?
And I remember after about a year of working on this project,
it was this cool 3D simulator that I really enjoyed working on,
except when I got to the math parts.
And then after about six months of that, I'm like, you know,
maybe I should take this as a clue that I should stop doing math and go do computers.
So very cool.
Nice to hear that.
Yeah.
So I know you because when I was looking for a place to host my website and get started,
I ran across Python Anywhere and I thought, wow, this is a super cool project you guys have.
It is amazing.
And so maybe you could tell me about that.
It's only moderately amazing.
It's pretty awesome.
Well, let's see.
So Python Anywhere is kind of, what is it?
It's a place where you can code Python in your browser.
And that could mean a lot of things.
And what it means for us eventually is like, I guess where we're really headed is to try and sort of be as Google Docs is to Microsoft Word.
Maybe we could try and be that to installing and running Python on your local computer.
Right.
So if you have Python that runs, you know, in the cloud with apologies for the buzzword, what can you do?
Well, so first of all, you don't have to install any software on your PC.
So you go along, you can come to our website and we'll give you a text editor, which is going to work.
And it's going to have syntax highlighting for Python and even maybe some error checking with the PyFlakes.
It's going to have a console just like you would have on your own computer and not just like a sort of line by line console, but like a real terminal emulator there.
So you can have tab completion.
You can run Vim or Emacs in it.
And we'll try and give you those tools that you're used to having on your PC in the cloud.
And what that gives you is the ability to kind of run things from anywhere.
And it gives you the ability to do more kind of collaboration things that are a bit harder to do on your own computer.
And then you can do some number crunching that maybe you can't do on your own computer because we can do maybe a little paralyzation for you.
And then finally, we can do web hosting.
So, you know, like we're already on servers.
It's that much, not much effort for us to then say, okay, well, we'll give your code some sort of public access to the Internet.
And so, you know, we end up having a lot of people just hosting websites on that.
Yeah, that's really cool.
Can you speak to, like, what percentage of users are doing what type of use case?
It's hard to tell, really.
Like, because we've got an awful lot of users of free users who come along.
And then, you know, like any website, there's some of them come and check it out and go, cool, and never come back.
And a lot of them will never talk to us.
So we're not too sure what they get up to.
But of the ones that pay us, an awful lot of them do use it for web hosting.
So, you know, we built this thing.
What it came out of was actually an online spreadsheet.
Okay.
So the company I work for is called Python Anywhere Now.
But when I joined it, it was called Resolver Systems.
And what they were building was a Pythonic spreadsheet.
So I mentioned I love spreadsheets earlier.
Yeah.
The reason I got this job is because I decided to do my thesis as part of my master's on spreadsheets.
That's amazing.
And what I thought I'd do is I'd phone out around a few companies that do spreadsheet software.
And, like, other than Microsoft, right, there's only, like, a very few of these, and they're small.
And I would just ask them, hey, I'm going to do a thesis all about spreadsheets because I'm crazy.
And probably if you guys love spreadsheets like I do, you want to sponsor me, right?
And there was one company stupid enough to say yes to that.
And that was Resolver Systems.
And that's how I ended up working there.
And they were making a Pythonic spreadsheet.
So, like, just imagine Excel, which works like Excel, except that when you want to script it, you get to use Python instead of using VBA.
That's a nice place to be, I would think.
It was really good fun and a great tool.
But, like, ultimately, if your pitch is you want to try and tell people to stop using Excel and use this other tool, it's a very high mountain to climb.
Yeah.
Even Google.
I think they're having some success with Google Docs.
But even for them and their reach, that's a hard story to tell.
Yeah.
So, like, for a small, like, five-person company out of London, it had a dedicated following of people who loved it because it was loads of fun.
But so that wasn't necessarily working.
So the first pivot was, like, let's take that online, right?
And let's build that tool.
Instead of having a desktop app, let's make it web-based and see whether people like that.
And they did.
And they liked the sort of number-crunching aspect.
But this was a sort of very, like, lean startup-y thing we were doing.
Let's reinvent this product online.
We did that sort of for three or four months.
I tried to gather a lot of user feedback.
And what people were coming back to us and saying is, you know, like, the coolest thing about this isn't the spreadsheet part.
It's just the fact that I can actually run Python scripts online off my computer in the cloud.
And I can just go there and it's there.
And so we said, all right, fine.
What if we dropped the spreadsheet bit and just had Python in the cloud?
What would that look like?
And that was Python.
Anyway, that's really interesting.
There's some parallels to Docker and .cloud, I think.
Totally.
In there, right?
Like, the thing that was just the foundation of your actual product became the product.
Yeah.
And the thing that worked so well.
Yeah.
The classic Silicon Valley pivot, although in this case, Silicon Roundabout pivot.
Yes, the Silicon Roundabout, which is, what, a few blocks away in London, that district.
Excellent.
Thanks for having me.
Now, let me take a minute and tell you about our sponsor for the show, CodeShip.
CodeShip is a hosted continuous delivery service focused on speed, security, and customizability.
You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed.
CodeShip supports your GitHub and Bitbucket project.
You can get started with CodeShip's free plan today.
Should you decide to go with a premium plan, Talk Python listeners can save 20% off any plan for the next three months by using the code TALKPYTHON.
That's T-A-L-K-P-Y-T-H-O-N, all caps, no spaces.
Thanks to CodeShip for sponsoring the show, and I encourage you to check them out right now at CodeShip.com and thank them on Twitter where they're at CodeShip.
CodeShip.com and thank them for joining us.
Is it on multiple data centers or is it on one?
No, at the moment it's just in one.
And as we grow, we get a few customers going, hey, can we get some in Australia or can we get some on the West Coast or whatever.
But U.S. East one, A, B, C, D.
Somewhere in northern Virginia.
That's it, yeah.
I have cousins down there, a lovely countryside.
Fantastic.
Yeah, so I think that's a really interesting place to be in.
Like I said, the way I found about you guys is I'm actually hosting my website for the podcast on there.
Right.
And that thing is super responsive.
I really like the experience.
So I tried to find these other places that would host it, and they're like, oh, yeah, we'll support Python 2 and Python 3, but, oh, we don't support Pyramid, which is one of the framework I use for the website.
Or, yeah, we support Pyramid, but we only do Python 2, and I write it in Python 3, and I'm like, you know, because it's a brand new project.
Like, I can write this in, like, Python 3.
That'll be fun.
Until I wanted to host it.
Then it was not so much fun.
And I just stumbled across you guys, and I think what you're doing is really, really cool.
You know, you support a whole bunch of different interpreters, yeah?
Well, Python interpreters, yeah.
Of course, yeah, of course.
So you've got several versions of Python 2, several versions of Python 3.
Yeah.
PyPy, which I thought was just because you can, right?
Why not?
That is really cool.
Did you have to do anything special to support that?
No, no, it's okay.
So, I mean, supporting things from the web hosting point of view means we use UWSGI or MicroWISGI,
if some people have it in the background, and that just has plug-ins for various interpreters,
including non-Python ones.
So it's just a matter of activating the ones that we think we can do.
So, like, we could actually, if we wanted to, go off and make RubyAnywhere.com.
The trouble is, none of us know anything about Ruby.
So we could do it.
Technically, it wouldn't be hard.
But then I think we're taking on a lot of users that would be asking us questions that we don't know how to answer.
Right, sure.
And there's places that host Ruby, but you guys are hosting Python really well.
Yeah.
And that's the sweet spot.
I mean, there's lots of people out there in there.
You know, so if you're someone going, oh, okay, I want to run my code on some servers,
like whether that's for web hosting or anything else.
But, you know, you can go to Amazon straight.
You can run your own server in a cupboard.
You can go to Google App Engine or Compute, as it's now called.
Or you can go to Heroku or you could go to .cloud in the old days.
And so it's about sort of figuring out where there's a space in that sort of fairly crowded market.
And I think the one is, like, let's focus on Python because that's what we know.
And there's plenty of business there.
And then let's try and say, okay, well, the hard work if you're running your own server is all the kind of sysadmin and configuration and maintenance.
There's this kind of tradeoff between, like, the ultimate flexibility is if you do everything yourself.
Right.
Go to Z2, start up in Linux machine.
Yeah, yeah, yeah.
But then it's your Linux machine you've got to babysit.
Yeah.
So it's more effort.
So, like, more flexibility, more effort.
And then there's, like, the other end back in the old days, like Google App Engine, where they would do a lot of the work for you, but they were also very restrictive.
So we'd say, right, well, you can use App Engine, but, you know, these are the rules about what kind of things you can run.
It's this version of Python.
You know, these things won't work.
And you have to, you know, like, all your requests will be killed after X seconds.
Don't touch the files.
Yeah, no database, no nothing.
And so we, like, so we're sort of somewhere between those two, trying to give, like, there's enough flexibility that people find it interesting.
Whilst solving enough of the problems that developers don't want to have to think about.
You know, scaling, backups, load balancing.
Yeah, so maybe we could talk about the sort of experience of creating a website in there.
And then we should also talk about other things like web job type stuff, which I think is interesting.
But you go there, you say, I want to create a website.
You can do that for free, right?
Right.
So I can create a free website as long as I don't care about the domain name.
Yep.
It would be .pythonanywhere.com.
Yeah, exactly.
Something .pythonanywhere.com.
Your username .pythonanywhere.com.
That's right.
And then I'm giving something that's really interesting.
It says, here is your bash shell in a browser.
Yeah.
To configure your environment.
Yeah.
And basically I can start with, like, a virtual environment.
Yeah.
Exactly.
I mean, so we haven't done enough about this, but we want to try and so, you know, people who learn Python, there's a sort of first learning curve, like, trying to get it installed and figuring out how pip works and can you install packages.
And we try and solve that problem for people by just saying, look, Python is already installed.
Here it is.
You just type Python or you click this button that says which version of Python you want.
And then, you know, like, how do you install packages?
Well, here's pip.
It will just work.
And also we've pre-installed a bunch of them just of popular things.
So maybe it's already there.
Nice.
Like, what are the popular ones you have installed?
We have, like, a file that we have overdone it.
There's, like, a thousand packages installed.
Like, SciPy, NumPy, Pill, blah, blah, blah, blah, requests.
And so many of them.
Yeah.
But in the web apps thing, it's the same thing.
And they go, okay, well, great.
I've developed a little, you know, I want to develop a web application.
What do I do?
Well, you know, now you're going to need to install this web framework.
You need to configure the following settings files.
You need to have a folder structure that looks like this.
You need to put your static files over there.
And if you're on a web server, then you'll want to configure, you know, a static file serving here and a database there and an environment variable there.
And we just want to try and do as much as possible to try and just kind of give users a thing that works.
They can get started with it.
And so we've tried to do a bit of that.
So if you want to start, like, a Django project, you can go to our web tab, go start a new project.
Do you want to use Django?
Yes.
And we'll install Django for you and set up a basic sort of run the sort of Python manage.py start project for you.
And there'll be a working Django site there.
And you can start with that.
Yeah.
That's the idea.
And, like, you know, we need to do more work.
The version of Django we have for Python 2 if I'm nitpicking is out of date.
So then, okay, you do have to use a virtual environment.
And that's a bit more complicated and blah, blah, blah.
I think the fact you have the virtual environment possibility there means that you can do whatever you want more or less on the system.
But you don't have to manage the infrastructure.
And so in my mind, I think you guys are a very interesting blend of platform as a service and infrastructure as a service.
So, like, I see it as infrastructure because I get a bash shell.
I can really kind of install stuff.
I can work with the file system.
It's kind of like a VM.
But it's platform as a service because I don't care what the web server version is.
I don't care about Linux and I'm setting that up.
Yeah.
You take care of it for us, right?
Yeah.
I guess.
So that's right.
Some other people will try and hide some of that stuff from you and just give you a thing where you write some config files and then...
Like Google Compute, for example, right?
Yeah.
And then, like, magic happens.
And ours is a little bit...
Maybe it's more about trying to recreate the kind of environment you have on your own laptop when you're running a dev version of a Flask app or something.
You know how that works.
Making that as much as possible the same on Python Anywhere where you just go, okay, well, if I wanted to edit a file in Bash or whatever, I can.
And it's just that this part over here will do the web serving of it.
Or if I want to view my log files, I can just, you know, tail my log file over here and there it is.
So I don't have to go through some complicated UI to go and retrieve the log file, you know, it can do it in Bash.
Yeah, that's really cool.
I feel like, you know, it's a nice middle ground because...
I'm getting more enthused about my own website by talking to you about it.
It's all you should.
This is great.
This is fantastic.
I'm here to make you excited.
Keep you going because you're doing awesome stuff.
So...
Thank you.
I feel like you're making me maintain things but making me maintain the right things.
So I've created a virtual environment and everything in the virtual environment is my problem.
But that's cool because I decide when I upgrade Pyramid or Requests or whatever, and that's all in line with what my app's doing.
But everything else I don't care about, right?
Like, would you upgrade Python 3 for me at some point?
Like, would I just magically switch to a new version of Python?
Well, you need to rebuild virtualenv if you switch to Python.
Right, of course.
That's right.
But we're trying to be a bit clever about that.
And we're trying to think of ways where you can say, you know, virtualenv is actually a bit scary for beginners.
Sure.
Like, they're used to going, all right, I figured out this command line thing.
I know that if I type Python, I'm going to get a Python prompt.
Okay, fine.
And then you go, right, but, aha, you need a virtualenv.
And so that when you do your command prompt, you have to check, have you activated the virtualenv, and is it the right one?
And, like, this is another point at which some big N is just going to go, what?
I just forget it.
Yeah, it's scary.
So people get that wrong.
And so that's why we try and give a default no virtualenv setup that might work.
And then we try to see if there's ways we can maybe build a bit of a GUI around the virtualenv stuff one day,
where you say, like, a virtualenv is a thing that Python Anywhere understands.
And so it knows what your virtualenvs are.
And we can give you a GUI that says, this is what your virtualenvs are.
And if you don't want to edit your virtualenv through bash with, you know, pip freeze angle bracket requirements.txt,
maybe we can give you a UI for that, and then you can selectively click on things and upgrade them.
Yeah, you could surface, like, the top 100 most popular packages, and they could check them off.
Yeah, yeah, yeah, yeah, exactly.
So things like that.
But that's, I mean, that's Vaporware, so I apologize for talking about it.
No, but these are good ideas.
I think it would really move it down farther.
So web hosting, you said, is kind of what people who are paying you, people like me, are doing.
But there's other stuff you can do as well, right?
Like, one thing I saw is I can run, like, scheduled jobs.
So if I want to, you know, like, run a script that, like, sucks down some sort of screen scraping type thing.
Absolutely.
Beautiful soup.
Yeah.
I can do that, yeah?
A lot of people do that, yeah.
So a lot of people are using it for web hosting.
A lot of people do scraping.
And so we have this thing, scheduled tasks.
It's basically cron jobs.
Yeah.
And you get to say, oh, yeah, every hour, every day, this sort of time, I'd like to run this script, whatever script you want.
And we'll go ahead and run that for you.
And maybe it's, you know, pulling down some data and saving it to a database, which maybe you've also got a web app that's then displaying that data.
I don't know, show me the train times or something.
Whatever.
Yeah, so people do it to, like, run automated jobs that they don't need to keep their own computer switched on for.
And then the third category of user, I guess, who might pay us are people doing big number crunching.
So every so often we get some people coming along going, right, I want to just download megabytes and megabytes of tweets and, like, just run massive number crunching sentiment analysis on them.
And so we have a system where if you use a certain amount of, like, CPU power on the system, we kind of put a quota on that each day.
When you go past that quota, we don't switch your stuff off.
We just put it in a tar pit where it gets slowed down.
And so if you want to do a lot of number crunching all day long, then you have to pay us to get a higher quota so that it's actually going to run at a reasonable speed.
Right.
That's the deal there.
Your web apps don't have that restriction right now, do they?
So they don't count towards your quota?
Yeah, yeah.
We find most web apps aren't big number crunching sources.
And we do actually have a thing where if a web request hasn't responded within, I think, the limit is five minutes, we kill it.
That seems reasonable.
It seems reasonable to us.
So, yeah, you could try and very cleverly circumvent our number crunching restrictions by building a web app if you want, but it would be pretty painful.
Yeah, no, I'm just more like thinking it's just not something you have to worry about with web hosting.
It's more of a jobs sort of consideration, right?
That's right.
Yeah, yeah, yeah.
Because I was feeling really good.
I'm like, after a half a day, I have a lot of hits on my site.
So I've used up 0.00 seconds of my time.
I'm like, wow, I wrote that thing pretty efficiently.
But not really, right?
No, that's right.
We don't count the web hits.
And the web model in general is that, you know, like, so it's like any, what do you call it, shared multi-tenancy?
I don't know.
Yeah.
But the point is that you can, like an airline booking system.
Oh, God, I just compared myself to an, I compared our website to an airline booking system.
This is the worst PR ever.
You know, like, we can host a lot of people on a big web server, and most of them are, like, not going to be doing very much.
And every so often, if someone hits the front page of Hacker News, you know, if you run your website on an Amazon micro instance, right, it's pretty fast most of the time.
And the way Amazon work is that, you know, they'll do really, really fast hits on requests.
And once you've used about 10 seconds of continuous CPU power, they throttle you down to nothing.
Yeah.
Right.
So it's great for running a website that gets low traffic, and it's super cheap, and it can be free.
But then if you hit Hacker News, your website just goes down.
Yeah.
Whereas, long on all.
When you need it most, it lets you down.
Like, the one you finally have gotten the word out about, and it's toast.
Right.
So whereas we say, hey, look, like, we're running, so you're on servers that have spare capacity.
They're big servers.
We use triple extra larges.
I forget which one on Amazon.
So when someone gets, you know, Hacker News, they just start using up more of the CPU on that instance for however long they're at the front page of Hacker News for.
And that's, like, we're fine with that.
That's part of the plan.
You know, if it turns out you're still at the front page of Hacker News after several days, like, we are going to notice, and we're going to have a quiet word with you about maybe it's time to start paying us.
Yes.
But in the meantime, it's a nice thing, so you don't have to be scared of that sort of getting slash dotted moment.
Yeah.
A friend of mine said, when I told him I was using your service, Python, and he said, well, why don't you just go to EC2 and create, like, a micro Linux?
I'm like, one of the things I really liked is it's really running on a big machine, and it has a lot of power.
It's just kind of shared, but, you know, those spikes kind of even out.
And so it seems like it's way more responsive than a micro instance for me.
Yeah.
So that's the idea.
It's like we can provide that.
Within reason, we can scale up for when you get crazy traffic unexpectedly.
And if it turns out to be forever, then we're just going to come after your money.
It seems fair.
Gently encourage you to upgrade.
It seems fair.
So other than, of course, talkpythontome.com, are there other notable moments that you guys can talk about?
Certainly, talkpythontome.com is our favorite website.
I would say so, yeah.
If it's not the one that's getting the most hits, it is certainly the best one.
Well, yeah.
So who do we host?
We've got a sort of funny niche in the Web2Py community.
So we host Web2Py.com, and we've got lots of users of that site.
And then a sort of case study example we sometimes trot out, which is a terrible example.
Again, bad PR, but it's just fun.
There's this guy.
He's a student at university, and he made a website called Stereodose.com.
Stereodose.com.
Is that D-O-S-E?
Yeah.
Yeah, and the Stereodose.com website is very simple.
What it says is like you come into a screen.
It says, pick your mood.
And it sort of says like energetic, mellow, a couple of other choices like funky.
And then screen number two says, pick your drug.
Right?
And you get to choose acid, mushrooms, ecstasy, weed.
And then it's going to auto-generate a playlist for you that's appropriate to your mood and drug of choice.
Fantastic.
Right?
So he's a university.
He's a college, right?
This is hugely popular.
I've asked all his friends.
So he knocked this together in no time.
It's a simple website, right?
And he hosted it with us.
And so he had the equivalent of hack and use.
I don't know what the equivalent of hack and use is for drug-induced playlists.
But he got on that.
And so he went from 10 hits a day to 10,000, 100,000 an hour.
And we were just like, yep, fine.
Very mellow hits.
Yeah, some of them.
Some of them were like really hyperactive.
Just keep refreshing the thing.
That's pretty cool.
Yeah, so that's an example.
So he made that thing.
Out of nowhere, it got popular.
And then we were just able to handle that fine.
And then gently suggested that now he's making some money off advertising.
Could he pay us X dollars a month?
I think, yeah.
Probably he's still on quite one of the quite low plans, like $20 a month.
Yeah, yeah, probably.
And so that's very cool.
Well, we do that for some of the first customers that have a big hit.
We like to reward them by keeping them around at a price that's quite frankly cutting our own throats, Michael.
Cutting our own throats.
What can you do?
It's what you have to do now.
It's what you have to do.
So we were talking earlier before we started recording.
You said you do a lot of Python sort of end-to-end of the whole thing.
So looking in from the outside, obviously, it's interesting that I can host Python there.
But can you talk a little bit about what the internal usage is and how that goes?
Yeah, yeah.
So it's all Python inside as well.
It was the same.
So the guys talk about Resolver Systems and that spreadsheet product.
They decided to start building it in Python and they were going to target Windows.
So they built it in Iron Python.
Okay.
And they went, hey, let's build it in Iron Python.
And then, like, obviously, it'll get too slow at some point.
And then we'll start writing some C or some C#.
And they found with that they just never reached that point.
Like, they just keep going in Python.
It was fine.
And so we had a similar approach with Python anyway.
And they said, well, Python is what we love.
It's the fastest way to get websites built that we're going to be able to do.
So let's just start with that and see if we ever need anything else.
And no, we don't really.
I mean, there's about four lines of lua somewhere.
And there's a bunch of JavaScript, obviously, which is a nightmarish help.
Yeah.
But other than that, yeah, no, it's all Python.
I'm just trying to think of any exceptions to that.
Python 2?
Python 3?
Well, yeah, Python 2.
Yeah, of course.
Well, we're joining a club with literally everybody else.
But I think you are doing a good deed to have a wide variety of interpreters, right?
Like, even PyPy is super cool.
Yeah.
I mean, yeah, so making the choice to sort of start supporting Python 3 for web apps, for example.
You know, just having Python 3 around, I mean, you can install it on your own computer in seconds.
So that's fine.
It's like supporting it for a real thing on the internet, like an application was, you know, we were looking at it going, is this going to be a niche concern?
But then we were saying, look, a lot of the people who come to us are beginners or hobbyists or not professional programmers.
And the message out there is, yeah, you should use Python 3.
And so to support them well, I think we did.
We did have to go, okay, well, even if we're not using ourselves right now, the wider world, yeah, our users want this.
So, yeah.
For sure.
That's cool.
Yeah.
I talked with Kenneth Wright.
Yeah, I had that.
About Python 2 and Python 3.
And, you know, it seems like it's some of the little things that make a big difference.
He said that having Django switch their docs by default to Python 3 made, you know, a noticeable bump in the usage for web apps for Python 3 just doing that.
So things like, you know, having it available.
Yeah.
Lowering the friction.
Yeah.
I think that's happening.
I heard the Kenneth episode, actually.
And he was saying, I wish Python.org would just decide which one the version is that they want to push and have that as the one that appears when you download.
And that should be Python 3.
And if you want Python 2, you should go and have to search for it.
Because ultimately, I think, yeah, beginners are using Python 3.
Educators are using Python 3.
Hobbyists are using Python 3.
Because, you know, why would you use the old version?
Like, if you don't know any different.
And so, Python 2 is kind of a legacy language.
It just so happens that this is the one that 90% of professional Python developers use.
But, yeah, I think we should make every effort, I guess, to start supporting Python 3 first for that sort of community.
Yeah.
He was talking about some really interesting ideas of, like, what is the killer feature we need to actually make people go, okay, it's time to switch.
Like, removing the global interpreter lock.
Maybe making, like, a super simple way to build distributable binaries that have no dependencies.
I think those would be really cool things to work on.
And I think it would make a difference.
You brought up education.
Yeah.
And you guys are probably used a lot for students and people trying it out.
Or there are, like, classes or university classes.
Like, okay, go create your Python in your account to start your project.
Yeah.
Yeah, there are, actually.
So, one of the things with Python is that it's the most popular education language for good reason, I think.
It's just really straightforward.
Like, you know, if you...
I'm not Guido Van Rossum, but if you were to try and design the most obvious way of writing a programming language, that's how it is.
Like, if you think about how a for loop works in Python versus C++ or JavaScript, you know, you just go, I just want to loop through these items.
So, for each item in the thing, I want to do a thing.
And you look at Python, that's actually it, isn't it?
That's fantastic.
So, for beginners, that's great.
Like, the learning curve is really nice for Python.
It's, you know, the Zen of Python is there.
Within the language, that's great.
So, that's working.
Outside the language, there's some peripherals where it's not so good.
I saw someone doing a poster about this at a PyCon three years ago.
Just saying, you know, here's what beginners find hard about Python.
Installing it is hard.
Like, first, you have to choose between two and three.
And then you install it on your system.
And, like, I don't know if you've done this on Windows recently.
I have.
It's beautiful.
Like, it doesn't add itself to the path.
And it still doesn't add itself to the path by default, by the way.
And so, then when people go, oh, just open up a command.
Try to type Python.
Like, it doesn't happen.
Python not found.
And, you know, it's like getting Python installed.
And then people say, oh, yeah, you need pip to install packages.
You know, so just, you know, apt-get install pip or brew install pip.
And beginners go, what?
What does this apt-get?
You know, we've got Windows.
Everyone's got Windows.
We have no apt-get.
And even the ones that have Macs, right, they go, oh, yeah, just install Homebrew.
And they go, what's Homebrew?
And they find a GitHub page, which is a terrifying thing, right, for beginners.
And the GitHub page just says, oh, yeah, you just need to download Xcode, which is 1.1 gigabytes,
just to be able to install this thing that's going to help you install this thing, right,
that maybe you think you need.
What is it, like, five Macs or something?
I mean, how big is pip?
I haven't even looked.
It's totally small.
Pip is tiny.
But, like, to install it on a Mac, people tend to say, oh, yeah, use Homebrew.
And then, so I have to, like I say, you have to hop by this 1.1 gigabyte thing,
which is going to help you install this thing, which is going to help you install this thing,
which finally is what you need to install this thing that you hope to use for some programming.
And, yeah, people have given up by now.
Yeah.
I think people sometimes forget what is obvious to us now, but the things you get hung up on,
like you're saying, like the path, you know.
It would be no big deal to us.
We could easily go do it.
It's not fun.
But to new people, they're literally out of luck, right?
Yeah.
It's like, what do I do?
Yeah.
And so you guys make that easier, right?
Well, yeah.
So teachers, you know, have to, if you're teaching Python, you have to, like, face that learning curve.
And if you've got a bunch of students in a school, then you go, right, let's get Python on all the computers.
Go.
And then the school IT department goes, well, we're an IT department, so we say no to everything.
It's our job.
You know, or I don't mean, you know, there's great school IT departments out there, of course.
But, you know, maybe that's going to take time or maybe, you know, whatever.
Or you are, you know, teaching Python to a bunch of people out there, maybe adults, or they've got a disparate bunch of laptops.
Some of them have got Windows.
Some of them have got, you know, like, Macs.
And you've got to try and make sure each one of them has got Python installed.
And you've got to try and make sure each one of them has got a text data to install.
And then you've got to be like, hey, if you're using sublime text, it looks like this.
Or if you're using idle, it looks like that.
Or if you're using a Mac, then type this command.
If you're using a PC, type that command.
And so, you know, a lot of people teaching Python is the first day has just been installing Python.
And they go, well.
Programming's not fun.
Programming sucks.
It's all about these little settings, right?
Right.
And so then if you just say to them, okay, well, forget all that.
Like, if you go to Python anywhere, you need a username, you choose a password, and then go.
Everyone has a text editor that works.
Everyone has the same bash prompt.
Everyone has the same version of Python.
And everyone has the same packages all available and pre-installed.
So if you want to do a class on NumPy, you can hit import NumPy.
You don't even need to explain pip install.
Yeah.
You haven't even mentioned that on Windows, you might not have, like, the clang compiler or GCC or VSVars.bat.
Yeah.
VSVars.bat.
That will literally stop the beginner in their tracks.
If, like, the path thing didn't get them, that will definitely get them.
Yeah.
So that's great.
So it's all set up.
Even the stuff that's harder to install, like NumPy, are the things that have C dependencies.
Yeah.
So teachers, like, have been, you know, coming to us for that.
And we've recently decided to try and do a little bit more for education.
As education in Python worldwide becomes more and more popular.
In the UK over here, the government have decided to make it part of the national curriculum.
So they're saying that you have to teach it in schools.
And this isn't just, like, you know, sort of secondary schools.
It's, like, it's middle schools.
So, you know, seven, eight, nine-year-olds are going to start to learn programming.
And, you know, what can we do to try and, like, help teachers who, like, some of these teachers, they're not computing teachers, right?
These are, like, generalist teachers who are just going, well.
They might be a science teacher or something.
I don't even like computers that much myself.
I don't know if I, you know.
So they're just trying to stay one week ahead of their students.
And so if we can do something to try and make their lives a bit easier.
So, yeah, we've been doing a bit of that recently, and it's been really cool.
Yeah, it's really great.
Last episode, I talked to a guy named James Curran.
And in Australia, he's involved in the curriculum there for high school and said that in Australia, they're requiring a text-based programming language as part of the high school curriculum.
Yeah.
And so that really natural.
Yeah, and he can't require two because we're sort of twice as good as Australians.
Nice, yeah.
So I think Python is the natural choice if they say text.
You know, you can do Scratch or something like that for beginners.
But as soon as it's, like, you've got to do a, quote, real programming language, I think Python is a good choice.
Yeah, in the UK, it's equivocated.
So people tend to teach HTML and Python, which, you know, you can have an argument about that.
Yeah, my daughter's in their high school have a class called Web Coding, and they learn HTML.
Yeah.
I'm not sure HTML and coding go together, but whatever.
They're doing something with computers, and it's cool.
Well, CSS is true and complete.
Accidentally.
Nice.
Okay, so talked about people getting started.
That's great.
Talked about the web hosting.
Another thing that you're really into, and you were recently at PyCon last year, right?
Mm-hmm.
Or was it this year doing a workshop or tutorial?
All the PyCons.
All of them.
Yeah, yeah.
All of them.
On testing, right?
Sure.
Testing a Django app.
Yeah, yeah.
Yeah, so that's my shtick.
So I guess it was in 2009, 2010 that I started with Resolver and what became Python Anywhere.
And I guess I'd learned enough Python and Django to be dangerous.
And I'd built my first kind of web application for a client.
And I remember how this went.
Have you read Dive Into Python?
I think I've skimmed it.
I haven't read it all the way.
To Dive Into Python is a good intro to Python for someone who already knows another programming language.
And in about chapter 10, he starts talking about testing and test-driven development.
And he goes, you know, we've learned about how Python works by RR.
Now let me tell you a bit about testing and how you can write tests and how you can even write them first.
And he uses a very traditional example, which is a Roman numeral translator.
So let's build a function that can translate Roman numerals into integers.
So like I is going to become 1 and II is going to become 2 and IV is going to become 4 and so on.
And he goes, so, you know, imagine how you do that.
And let me show you that if you actually, you can write tests for this.
You can write a thing that says I should equal 1 and II should equal 2.
And you can run that as a program which tests, you know, the thing you're about to write.
And then when you write it, you know when you've got the right answer.
And secondly, you know, you're going to be able to modify your solution and know that it's still correct.
And I remember reading that and going, you know what, that's a really good idea.
That sounds like something you really should do.
It's like it's healthy.
It's good for you.
It's like flossing your teeth.
And what happened next is I got my first real client and there were real deadlines.
And all of my good intentions about TBD just went right out the window.
And besides, by then I'd had a full seven or eight days of experience with Python and Django.
You had it all figured out.
I thought I was pretty smart.
I figured I could get away without tests.
And yeah.
Yeah.
Actually, I was fine.
I was absolutely fine.
Yeah.
At first.
And then.
And then you started maintaining that thing.
Yeah.
I mean, you know, I read a thing about like called Don't Repeat Yourself.
And I was like, right, well, I better not repeat code.
And so like I started to that ended up being like sort of an inheritance class hierarchy, five levels deep.
Did you hear that siren?
Well, it's 4 p.m. on a Tuesday.
So I guess that means it's a perfect time for a fire alarm test.
It was ridiculously loud.
Now, let's pick up the conversation again after ears stopped ringing.
So you had written this app and it started out all fine.
Then you heard about the derived principle.
And you're like, yeah, that's a good idea.
Let's do that.
Yeah, yeah.
Let's do that.
Let's have an inheritance hierarchy, five levels deep.
And like for some reason, I decided that like somehow I'd got to eval statements, right?
So there was eval statements in the code doing stuff.
And, you know, like it was no longer a one page app.
You can just check works by like checking that one page.
Like there was 25 pages and they were all interdependent.
And I would change the thing over here and go, oh, I think I could.
Oh, no, that's going to break that one over there, I think.
So, but what?
Maybe if I override this method.
And like pretty soon I had like a nightmare of crufty code and I was scared to change it.
And, you know, like all of those things happened to me.
So, yeah.
So then I got a job at Resolver and they went, you know, we do test driven development.
I'm like, oh, really?
Okay.
Maybe that could help.
But I still dragged my feet about it.
But, you know, yeah, they showed me this thing.
And so it's an extreme programming shop.
Everything is pair programming.
Really?
That's cool.
Yeah, yeah, yeah.
I mean, it was like honestly so lucky for me to learn from these guys who've been doing it for ages.
And, you know, if you're a pair programming and you just sit next to someone and they start asking programming and you just sit there going, why?
Why?
You know, and it's just like a sponge just sucking in all this knowledge.
So it's an amazing way to learn.
It's almost like an apprenticeship type of thing.
Right.
Yeah, I mean, that's really true.
Yeah.
And so that's, yeah.
So I learned all this testing and I decided to try and kind of like regurgitate it a little bit and turn it onto some online resources.
I made a couple of blog posts.
I rewrote the Django tutorial.
You have a website, right?
Yeah.
It's called obeythetestinggoat.com.
Fantastic.
I used to have a website called tddjangotutorial.com.
And what it was was like the official Django tutorial except test driven.
So it tests at every stage.
That's nice.
And that turned into like a sort of tutorial I would do in real life and at conferences.
And that eventually turned into a book which is published with O'Reilly.
It's called obeythetestinggoat.com.
Unfortunately not.
No, I had, yeah, we discussed this with my editor and obeythetestinggoat is going to be too arcane a title.
So that is actually the tagline or the subtitle.
So the book itself is called test driven development with Python colon or comma obeythetestinggoat colon.
And we actually argued about this.
I wanted an exclamation mark but they insisted on a colon.
So it's obeythetestinggoat colon tdd with Python, JavaScript, Django and pals or something like that.
That's fantastic.
So what kind of stuff do you cover in there?
So yeah, it's test driven development but instead of taking that sort of classic slightly artificial example of a Roman numeral calculator which everyone does or a banking currency converter, right?
There's always these TDD tutorials with like an example function and it goes, oh yeah, but it's nothing like the code you write in real life.
It has no dependency.
Right.
It doesn't touch the file system.
It doesn't have like a huge bunch of code calls, all that kind of stuff, right?
And so I just did the opposite of that.
I went like, okay, well let's do actual web development.
And we'll just have all the dependencies.
So yeah, it will be a web application which needs a web browser and it needs the file system straight away because of templates and there's going to be a database and all that is like from the ground up.
But maybe that's a hideous mistake.
I don't think so.
I think a lot of those, I do a lot of training for my job and a lot of people have the same reaction that you were saying is like, it's all well and good to tell me about this stuff but this is a fake thing.
It won't work in my complex company because X, Y, and Z.
And if you don't see it for real, then who's going to believe it, right?
So yeah.
I mean, it's still a fake thing.
I mean, I go through the development of a web application from scratch, but it's a simple web app, right?
It's a to-do list app because that's everyone's example and I have no imagination.
So it's the simplest possible web app, but it does have a database and it does use a web browser and it does do things to the file system and whatnot.
Nice.
So what are the testing frameworks and things?
Like do you use pytest, Unitest, Nose, Clean Green?
What's the story on it?
It's been Clean Green.
Nathan.
I met Nathan who did this green testing framework.
He's a lovely guy.
His GitHub username is CleanCut and that's because he's just got the most preppy set of teeth.
I think he's saturizing himself a bit.
Nice.
Yeah.
No.
So for the book, I just use the kind of standard air quotes tools, which are the UnitTest, Standard Library, Test Framework, and the Django Test Runner because that's what most people use.
And at work, we use those as well.
And we've also started experimenting a little bit with pytest.
So there's a few talks out there if you look at it.
I'm saying pytest versus Nose versus UnitTest.
What are the pros and cons?
And the Noses and pytest do come off well when they say, you know, like, UnitTest came from the Java world and this sort of like XUnit thing, which involves classes and it involves methods.
And, you know, they've got these camel case method names, which is they've got them for historical reasons.
And people new to Python will look at that and go, oh, that's weird.
Why are we using camel case here?
They don't look like methods on anything else I've ever seen.
And so moving away from that, the pytests and the Noses who have a more just why have a class?
There's no point.
Let's just have functions because that's all we're really using these classes for.
And that has a lot of appeal.
And so I've dabbled with that and we've dabbled with that at work.
And I think they're kind of cool.
So I would definitely recommend people take a look at those.
And particularly, I think pytest has got a lot of – I get the feeling that, you know, people have been out there and looked at these things.
pytest is coming out as like the new kid on the block or the one where people go, yeah, yeah, yeah.
Having assessed all three, this is the one to look at.
What do you think the benefits are there?
Is it more Pythonic?
Yeah.
Is it easier to use?
Yeah.
So those two things, for example.
Yeah.
You know, like so in unit test, you're going to have – you know, you go, well, if I write a test without any framework, I go assert thing equals three.
Right.
This is actually – I do this in the book to explain why would you use a test framework.
And you go assert thing equals three and it fails.
And you get a thing saying assertion error.
But it doesn't say, well, thing you expected was three was actually equal to four.
That would be useful.
That would be great.
So you can write your own error message handler, right, by, you know, using the sort of comma second argument to the assert keyword.
But that's hard work.
And you know what?
People have discovered these problems before and there are standard solutions.
And one of them is use unit test, put in a test method.
You get set up and tear down, which is a common requirement in tests.
And you can go self.assert equal thing with thing and then it's going to give you a nice error message.
And I think that's all very well.
But you've gone through the trouble of making a class and making a test method.
And you're – I think Raymond Hesinger was saying the other day about Pepe's indentation.
You know, when you've written a test class, you're already three levels of indentation down before you've written any test code.
And you're going to go self.assert equal.
And there's also self.assert items equal if you just want to compare list items without the order.
And you've got self.assert is none.
And you've got assert multiline equal for strings.
And you've got assert rejects matches.
You've got assert – you know, like I can't even remember them, right?
Yeah.
And so you have to start looking at the docs whenever you're trying to compare two things.
And I think pytest is superior to that in which they just go, look, just say assert and then a thing.
And the test framework will figure out what the thing was you were asserting.
And it will try and give you a sensible error message without you having to be clever about it.
Yeah, that's fantastic.
And I really like that.
Just the assert keyword that you've seen before and a thing.
And other than that, you just put your tests in methods that start with test.
There's no need for a class unless you really want one.
Sure.
Very nice.
Well, I've been using unit tests.
Maybe I should be checking out pytest.
Yeah.
So you can run pytests on existing unit test tests.
Yeah.
And so there's a migration path there that will work.
And then the weird thing.
So the fact that the assert keyword, it will magically tell you what the two values were,
is the first bit of pytest magic that people raise their eyebrows at a little bit.
The really magic part is the way it does sort of set up and tear down.
Which is, you know, in unit tests, we write a methodical set up and a methodical tear down.
And that seems instinctive to us now because we're so used to it.
It's been beaten into us over the years.
But what we really want, and so that the pytest world is more kind of functional.
And what they say is, okay, well, if you want some setup to be done in a test,
you're going to define a method that does that setup.
Well, define a function that's going to do that.
So you define a function that says, like, prepare database, for example,
that's going to, like, set up a test database for you.
You do some stuff.
And then if that function is called prepare database, you put a decorator on it.
Say this is a fixture.
pytest's word for test setup stuff is a fixture.
Which is slightly different from the way Django uses the term, but bear with us.
Pop a decorator on it.
And then take any of the tests that need that fixture.
And then you just say, add an argument to that test.
Which, first of all, that function didn't have any arguments.
Now, you add an argument to that test.
And you just give that argument the same name as the function you'd find earlier.
And then when you run it, we'll magically find that function, execute it,
and inject it into your test for you.
That is magic.
Or a crazy convention.
Well, or a convention, right?
And, I mean, setup and teardown are kind of magic as well.
Like, there is something happening to make those happen.
Yeah, absolutely.
And so, like, is it any more explicit?
That's debatable.
I think it's just...
No, it sounds great to me.
But then you can have fixtures inheriting from fixtures.
So, if you have a fixture function called prepare database,
maybe that inherits from prepare file system.
And so, similarly, you can give an argument to a fixture that's also another fixture.
And, you know, like, yeah, yeah.
It'll get...
It's like a Russian doll.
It'll get pretty fun pretty quickly.
Yeah, that's very cool.
So, do you discuss code coverage?
I don't, no.
It's a lacuna.
I guess we've never used it at work because we've got such a sort of religious adherence to TDD.
The guy next to you is the code coverage.
Well, they are.
And the methodology is in that, like, we basically don't allow ourselves to write any code in production that hasn't got a test.
So, you know, we've kind of assumed our coverage is 100%.
And so, it would be probably educational for us to actually run coverage one of these days.
But, no, I don't talk about it in the book.
I mention it at the end going, hey, here's the thing you should check out.
Yeah, here's the thing you should check out.
That's cool.
You know, you can't cover everything.
Yeah, no, of course.
You have to ship.
Even when it's a book, you have to ship at some point.
Yeah, yeah.
It's the trouble of anyone writing a book.
But, no, I do find that.
So, I talked about it being real.
In the book, we build a to-do list app.
So, we go ahead.
We learn how to database to-do list.
We start with a to-do list app that has, like, one item.
Then it has many items.
But it's the same list for everybody on earth.
And then there's, like, multiple lists for multiple people.
Great.
And then, like, once we've got that working, I go, okay.
Well, you've made a really ugly website.
Let's do some styling.
Because, like, it's not just about a Django view that returns horrible HTML.
Let's put Bootstrap on there and use CSS and make it look a bit presentable.
Which is something that, you know, most guys might not cover.
And then that's Chapter 7.
And then Chapter 8.
I'm like, right, good.
We've built a basic web light.
It's fine.
I know you can't delete to-do items.
You can't edit existing ones.
But that is a working to-do list app.
It's a minimum viable product.
So, now we need to ship it.
And so, like, Chapter 8 is deploy it to a server.
And I'm just going to go through how, like, now that you've got your tests, can you run them against a server?
Can they actually help you deploy as well?
And so, yeah, that gets even more real, I guess.
Yeah, very cool.
And a fairly fierce learning curve.
Yeah, it seems like a good place for people to start.
So, I'll put a link in the show to the book.
So, thank you.
Yeah, so you were talking about databases and dependencies.
And I'd like to come back to Python anyway to start a bit and talk about that a little bit more.
So, you guys have MySQL.
Sure.
Your Postgres.
Yeah.
Postgres.
And then I noticed something interesting, I think, in an email from you guys.
I think I'm remembering this, right?
So, now you're using containers.
Oh, yeah.
For your Postgres.
Sure.
Yeah.
So, is that Docker?
The Postgres ones are, yeah.
Yeah.
Well, so I guess anyone that's building a thing a little bit like what we're building eventually comes across containers.
Like, this is .cloud.
We're in a similar business and they invented Docker.
Yeah.
So, if you're running a lot of people's untrusted code on your servers, you've got to figure out a way of isolating them.
And the way you do that in Unix is with a bunch of cool tools that put together a tool these days,
containerization.
So, we've used bits and pieces of these tools everywhere.
And the thing with MySQL is the way we provide that is if you host a MySQL server, you can do multi-tenancy fairly easily.
You can create different user accounts for different users and you can say this user has permissions on this database and this user has permissions on that database and you're fine.
They're pretty well sandboxed from each other.
Postgres isn't so good in that respect.
It's not really designed with a multi-tenancy model in mind.
And pretty much in Postgres, unless you've got super user access to the server, you can't really do anything.
And none of the cool Postgres stuff is possible without being a super user.
So, you can't really do multi-tenancy Postgres.
So, we were forced to say, okay, well, then we can't just have one Postgres server that runs everyone with user accounts on the same server.
We're going to have to have multiple servers.
Everyone's going to have to effectively be a super user in there.
And a sensible way of doing that seemed to be to run each Postgres instance in some sort of container.
Yeah, that's really cool.
A virtual machine probably wouldn't be the right answer.
Yeah, too slow, right?
I mean, this is why everyone's using containers.
They're too expensive.
The density on the servers just isn't there.
Yeah.
If you're offering something for free, density matters.
Yeah.
So, that was nice.
So, that was where, yeah, we used Docker for the first time in production and we used Py.Test for the first time in production.
So, the Py.Test and Docker, like two experiments at the same time.
Terrible idea.
Great fun.
Sounds excellent.
And, yeah, so that's how that works.
We've been happy with it.
Uh-huh.
Cool.
And I saw on your features you're considering maybe sometime maybe was MongoDB.
Yeah.
Would that be a thing that might show up over there?
It might be.
I think we're looking in the short term to probably outsource that.
So, there's, I can't remember, there's a couple of companies out there that do MongoDB as a service.
Sure.
MongoHQ, MongoLab, ObjectRocket.
There you go.
All of these guys.
I think I'm going to say the three that come to my mind.
Well, I, you know, since we haven't settled on it, we won't big up any of them in particular today.
Yeah.
Because maybe they'll give us a good deal or something.
Yeah, exactly.
It's time for a bidding war.
Yeah.
So, I think what we do for Mongo maybe in the short term is pick one of those, try and build a bit of integration, just make it really easy for people to go, oh, okay, start a Mongo service.
And it will actually go out to, you know, whoever it will be.
Sure.
Create a user account on there.
And then, you know, wrap it up.
Just kind of delegate, wrap it up, make it amazing.
Yeah, that's cool.
And a lot of those guys are either on AWS or direct connect to AWS.
So, it would be relatively.
Yeah.
So, that's one of the fun things about Python Anywhere, actually, is if you ever do a Git clone of a massive repo and you're sitting there and it's going, okay, downloading 400 megabytes or more, not everything is fast on Python Anywhere.
But that is one of the things it is because it's in Amazon's data centers and GitHub's got some servers right next door.
Yeah.
When you get a repo, it comes down super fast.
Yeah.
Which is great.
Yeah.
I mean, other file system things aren't so fast because we have to have the challenge of running multiple servers but needing to give people access to the same file system no matter what server they're on.
You know, there's NFS in the background and that's not the fastest thing ever.
Yeah, of course.
But, yeah.
No, for doing internet stuff, being in a data center in the first place is great.
That's cool.
And that's how I get my source code onto the machines.
I just get, you know, get pull.
I've cloned it, set up my virtual environment, point it at the Git repo.
Yeah.
Is there a way to set up continuous delivery?
Yeah.
Yeah?
So you can, continuous delivery, so you can hack it a little bit.
Yeah, like with a web job to do a Git portal?
That sort of thing, yeah.
You could do that.
But you can, you can, you can set up, because like Python Anywhere is essentially a Linux server, you can set up a Git repository on it, one that you can push to.
So there's a, we've got a blog post about this, but you can set up a Git repository that will, that you can push to, set it up as a remote in your own local computers one.
And then you can do Git push Python Anywhere.
It'll arrive on Python Anywhere.
You can set up some hooks on Python Anywhere.
When they see new code coming in, maybe they'll even run your tests.
And then they can do a little thing that will like bounce your web workers and, and your website will be deployed.
Nice.
So you can, you can sort of hack it.
So we haven't built that in yet.
But you can, you can hack around a thing like that if you feel like it.
Yeah.
Cool.
Is that something you're considering?
Maybe, maybe not?
Well, we always have to think, you know, we have to serve, we have to serve the beginners and we have to serve the more advanced people.
Right.
And so the model is.
That what I'm describing is not very much in your original mission.
Right.
Yeah, yeah, yeah.
So like continuous deployment, right, as a thing is not the first thing, you know, it's not the first hurdle that people walk up to.
And so we like, we'd run, I think maybe for now we'd rather like say, can we make it easier for people to use virtual M's or can we make it easier for people to upgrade their version of Django?
If they're a beginner, we're like trying, trying to make that learning curve a bit smoother.
Yeah.
It seems like that kind of stuff would actually be way more broadly valuable.
Yeah.
I don't know.
It's different audiences, right?
Yeah.
Not necessarily to me because I'd like continuous integration as a button, but our continuous delivery.
But for most people will come.
It seems like that would be the right place to focus.
Yeah, yeah, yeah.
I mean, there's so many things.
It's hard to prioritize.
That's a good problem to have, right?
There's all this cool stuff you want to do and you got to pick.
Yeah, yeah.
So, you know, see what your users are asking for, right?
Yeah, IPython notebooks they want.
And we're trying to try to figure out what people are doing.
Oh, yeah, that would be cool.
Yeah, yeah, yeah.
I mean, it is.
You're getting IPython running in your local computer isn't totally straightforward.
It's not, especially on Windows because you've got some C dependency somewhere or whatever.
There are, there's anacondas.
Right, that's true.
Yeah, some of the prepackaged environments.
Before that, there was the M4 scientific Python distribution.
It's all the same problem.
Like, yeah, there's the things that should be easy that aren't.
And so, yeah, yeah.
We're going to see what we can do about it.
Yeah, so if you make that open web browser click button, that'd be fantastic.
Yeah, yeah, yeah.
Nice.
So, I think that's kind of getting to be a decent amount of stuff we've covered in the show.
Anything else you want to add?
Now, I promised myself I was going to say a thing and it's gone.
Let me ask you something else and maybe it'll sneak back into your subconscious.
So, one of the things I ask a lot of the guests on their way out the door is what is your sort of favorite package or library in Python?
Do you have some favorites?
You know when you type in pip install requirements.txt and it goes no package called this point requirements.txt?
Because you have to type in pip install dash r requirements.txt.
Yeah.
Right.
I've been trying for a little while to figure out if I can upload a package to PyPI called requirements.txt somehow.
So, that when you accidentally mistype pip install requirements.txt, it installs my package.
And because the setup.py is like, you know, completely unsecure.
It's just straight.
You can do whatever you want.
I was just going to open up Firefox to rickroll people.
So, that pip install requirements.txt would just rickroll you.
I think that would be great.
I think the PyPI guys have got there ahead of me on that.
So, it's not possible that I've found.
But I thought I'd throw that little evil idea out there in the world to the listeners of the podcast.
If you guys can figure it out, it would be hilarious.
That would be great.
Maybe slight misspellings of the word requirements.
Yes.
Get them like 10% of the time or 5% of the time.
Maybe requirements text without the dot.
Yes.
Right.
You could maybe catch a few people like that.
That's fantastic.
All right.
Final thoughts.
Have you thought of it?
I know.
That was it.
I think that was actually the rickroll thing.
That was the rickroll.
Awesome.
I must bring that up.
That's fine.
Yeah.
That's really good.
So, Harry, thank you so much for being on the show.
Yes.
It's really interesting.
I'm a huge fan of Python Anywhere.
If someone's out there listening and they're like, that sounds cool.
I want to check it out.
I want to play with this idea of a bash shell in my browser.
Whatever.
How do they get started?
So, pythonanywhere.com.
Python, P-O-I-T-H-O-N, anywhere, N-A-N-Y-W-H-E-R-E.
Or you can go to pythoneverywhere.com.
That redirects to pythonanywhere.com appropriately.
You can also go to python.org.
There's a little Python console on the front page there.
You can click the button.
You get a live console.
That's supplied by us if you feel like it.
And the other thing I have to plug or my editor will kill me.
I'm going to plug my book.
So, the book is available at obeythetestinggoat.com.
It's available both for free and for purchase.
So, the whole thing is available online for free for the zero pounds or dollars or anything.
But if you feel like buying it, you can as well.
And, yeah.
Those are the two websites that you have to go to.
pythonanywhere.com.
Obeythetestinggoat.com.
And your testing tutorial you did at PyCon is on YouTube, right?
Sure.
Yeah, yeah, yeah, yeah.
Is that just in the...
I think I actually have it in my list.
In one of the previous shows, I said, like, here are the essential presentations.
Yeah.
From PyCon 2015.
And I think it's in there.
But I'll put a direct link to it in the show as well.
For sure.
Yeah, yeah.
I mean, there's an O'Reilly official video you can buy.
Okay.
Maybe I'll link to that as well.
You can if you want.
But, you know, there are also free versions of all these things.
I'm no great believer in, you know, this is the internet.
This point is pretending that you can charge for digital things and that people won't find a way of getting them for free if they want them for free.
So I'm all about saying let's have them for free.
You know, your choice is between having it for free without your consent and having it for free with your consent.
And my choice is with my consent.
So help yourself to the stuff for free and pay for it if you feel like it.
Yeah, that's great.
I think people are more generous than a lot of businesses give them credit for.
And they're, you know, they'll say thanks and they'll buy something if it really helped them.
Well, so we're in danger of overstepping the end of the podcast here.
But I'm sort of a bit into internet activism.
I'm a member of the Pirate Party here in the UK.
And for me, it's worked very well.
Like I say, put my stuff online for free and people will pay for it.
And so I would love to expose that as an ideology.
I would say that it's a different calculus for me than it is for Stephen King.
If I put my book online for free, the people that read that, why are they reading a book about test-driven development for web development, right?
They're not reading that like to…
It's not a scary…
This is not a holiday airport thriller, right?
This is a thing they're reading.
They're reading because they want to get better at programming and they want to get better at programming because they're probably doing it for a job for money, right?
So I think people see the very act of reading that book as quite a commercial transaction.
And when I'm saying, hey, look, it's try before you buy.
Like, so read this.
If you get value out of it, you know, I'd love it if you paid.
I think people do go, well, I was reading this in the first place for monetary reasons, so I think I should probably pay.
Whereas, you know, like if Stephen King is sitting there putting all his books for free out there, you know, you're reading that.
You're not reading it for monetary reasons.
Your personal value of it is not the same as if it means a better job.
Exactly.
So maybe it's easier for me to upsell people to the paid version than it would be for Stephen King or something.
But yeah, no, absolutely.
It works for me.
That's cool.
Great.
All right.
Well, thank you again so much for being on the show.
It's really nice to meet you.
And I think it'll be a great conversation for everyone to listen to.
Great.
Thanks, Michael.
Yeah.
Bye.
This has been another episode of Talk Python to Me.
Today's guest was Harry Percival.
Follow him on Twitter where he's at H-J-W-P.
This episode has been sponsored by CodeShip.
Please check them out at CodeShip.com and thank them on Twitter via at CodeShip.
Don't forget the discount code for listeners.
It's easy.
It's Talk Python, all caps, no spaces.
Remember, you can find the links from the show at Talk Python To Me.com slash episodes slash show slash 10.
And if you're feeling generous, check out our Patreon campaign at Patreon.com slash mkennedy.
Be sure to subscribe to the show.
Visit the website and choose subscribe in iTunes or grab the episode RSS feed and drop it into your favorite podcatcher.
You'll find both in the footer of every page.
This is your host, Michael Kennedy.
Thanks for listening.
Bye.
best.
First developers.
Don't forget.