Today, you'll learn how Patreon is helping people live their dreams, building amazing
creations for the rest of us.
It's time for Talk Python.
This is show number 15.
Today, our guest is Albert Hsu, and this episode is recorded Tuesday, January 2nd, 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 talkpythontome.com.
This episode, we'll be talking with Albert Hsu from Patreon about migrating to Python.
I'm really fortunate to have CodeChip and Hired sponsoring the show.
Let me take just a few seconds to tell you about them.
CodeChip is a platform for continuous integration and continuous delivery as a service.
They encourage you to always keep shipping.
Please take a moment and check them out at codeChip.com or follow them on Twitter, where
they're at CodeChip.
Hired wants to help you find your dream job.
Hired is built specifically for developers looking for new opportunities.
Check them out and get a very special offer at Hired.com slash Talk Python to Me.
And you'll find them on Twitter, where they're at Hired underscore HQ.
Let me tell you how we got to the show.
It all started with me whining about bandwidth charges on Twitter, saying it was so expensive
to run a podcast.
Look at these things grow.
And then Justin Spain from Chattanooga, Tennessee, who's at JWS Music on Twitter, said,
why don't you start a Patreon campaign?
Of course, when I read that, I thought, well, what's a Patreon campaign?
Then it turns out that Justin was right.
Patreon is actually perfect for things like podcasts, blogs, frequent videos, and even
open source projects.
Listeners, readers, and so on, pledge a small amount to each release, in my case, each episode.
And when one of these episodes ships, a small amount of money is contributed back to me to
help keep the podcast going.
If you want to learn more about my campaign, you can find it at Patreon.com slash mkennedy.
So fast forward a month, the guys at Patreon noticed my campaign and happened to be making
a company-wide transition to Python 3 from PHP.
So they reached out to me on Twitter, and we thought it'd be cool to talk about their port
of their product to Python.
And we talk about how that's going.
In case you don't make it all the way through the whole show, it's going great.
I also want to take a moment and say a special thank you to the 30-plus patrons who are already
supporting the show.
Right now, your contributions are covering a little more than the monthly bandwidth expenses
for the show.
This allows me to use my sponsorship money for extra benefits, such as creating searchable
transcripts and things like that.
But more importantly, your support has given me the confidence to push hard on making this
podcast all that it can be.
And of course, there's still a long way to go there.
So thank you for the help.
You might also be interested to hear that Patreon is hiring Python developers and data
scientists.
Check out patreon.com slash careers if you want to be part of a sweet team in San Francisco
who are building out a business and putting a dent in the world using Python.
At some point during the show, I make a statement that PHP is one of the most dreaded languages
and technologies of 2015.
I was quoting from the Stack Overflow 2015 developer survey.
You'll find the links in the show notes.
And I have a bit of a correction there.
Sorry.
It was Perl that was part of the most dreaded list, not PHP.
PHP didn't make the top nine.
However, I suspect maybe it's lingering just off stage at place 10 or 11 or 12.
And in case you're wondering, what is the most dreaded technology on the list?
It's Salesforce.
All right.
Finally, the Talk Python to Me t-shirt Kickstarter project is still running.
It will be open for nine more days.
So be sure to visit bit.ly slash Python shirt to reserve yours.
It's a cool and comfortable cotton shirt that will tell the world about your unabashed love
for Python.
Now let's get to the conversation with Albert and Patreon.
Albert, welcome to the show.
Hi.
Thanks for having me.
Yeah.
I'm really glad that you guys contacted me.
And I'm looking forward to the conversation.
We haven't really had much talk on moving from one technology into Python.
And that's our main subject today.
So thanks for being here.
Thanks for reaching out.
And we always, Patreon is a creator-first platform, and we'd always like to support our creators
in any way we can.
Yeah.
So we'll get to Patreon in just a second and sort of how this show came into existence.
But I always like to start off the show asking my guests who have achieved a lot in their
careers.
And how did you get started in programming?
And how did you come to start using Python?
So I actually got started with programming pretty early.
I actually borrowed my brother's computer science A-B textbook when I was really young and just
went through some of the exercises in C++.
It wasn't the best way to learn things, but it got me introduced to a lot of really small
things like how to print things out to a screen, how to do for loops.
And back then, I was pretty entertained just by doing really simple programs like little small
games where you can put your name and someone outputs your name right back at you.
Yeah.
I think we've all written those types of apps, and they're super fun.
Just the feeling of satisfaction and accomplishment is surprising for you, right?
Yeah.
Especially when you're really young and your standards are lower.
But as I sort of grew up, I started programming a lot more on calculators, on TI Basic.
I decided to pursue programming as my major in college.
And I was still pretty gung-ho about C++.
I thought it was a hardcore language.
I thought that all the hardcore programmers would do C++.
Until freshman year, someone introduced me to Python, and I thought it was kind of a weak
language because it didn't feel as hardcore.
Yeah.
I think that's a common feeling, or maybe misconception is a better way to say it.
But a lot of people feel like the really tough guys do C++, and they're right down there in
the memory and on the metal.
And all you other guys are just fooling around, orchestrating our code or whatever that we write
in C++.
But I'm not sure that's really true or fair, is it?
That was my impression at the time.
And what really changed me is when I actually had to do a lot of project courses in college,
I realized I could actually do things correctly and quickly.
And in terms of performance or the standards of the code, much better in Python than I could
in C++.
And I just continued using Python whenever I could all through college.
I didn't get a chance to use it professionally until about a couple years ago when I started
at a company called Quora.
Quora, is that the QA site?
Yeah, that's right.
Quora is a question and answer site.
I started it pretty early and saw a lot of the really cool things that they were doing with
Python.
A lot of stuff with generators and with metaclasses and decorators.
And it really turned me on to Python as a really serious language.
And part of what I want to do at Patreon is take a lot of those more advanced Python techniques
and bring it into our infrastructure.
Oh, that's really cool.
But when you got to Patreon, it wasn't originally in Python, was it?
No, it was in PHP.
It started in PHP because that was the fastest way to bring the product to life in the early
stages.
But as the product grew and as the engineering team grew, it started to become pretty clear
that PHP wasn't going to scale with the team.
Is that from a performance perspective or from an adding new features and maintainability
perspective?
The number one thing was maintainability.
And it's not 100% like PHP's fault, but rather PHP allows you to do certain things that make
the code way messier than you want your core code to be.
A lot of things with PHP just allow you to do things very quickly.
And when you're adding more and more engineers, when you're going from one engineer to two to
three to ten, you don't necessarily want to do everything the fastest possible way.
We did want to do things fast.
In fact, the concept of shipping quickly is still important to our engineering culture.
But we want to be able to ship quickly in a way that's maintainable and a way that uses the proper
abstractions in a way that isn't copy pasting, I guess.
Let's talk a little bit about what those differences are and stuff.
But before we do, maybe you could tell everyone, what is Patreon?
Yeah.
Patreon is a subscription funding for creators.
And the way it works is that patrons will pledge a set amount per release.
Every time a creator publishes a new creation, so like a webcomic, a video, a blog post, a podcast,
anything, funds are transferred from patrons to the creator.
We launched in May of 2013.
And as of summer 2014, we announced that patrons were sending over $1 million monthly to creators
through Patreon.
A million dollars a month.
That's amazing.
Yeah.
And we're still growing.
We just passed $2 million very recently.
And the company itself is about 24 people.
We're headquartered in Soma in San Francisco and actively hiring.
Okay.
And they're doing Python.
And I suspect you'll reach a lot of intrigued Python developers out there.
So that's a good message.
Yeah, that's the hope.
Yeah, excellent.
So I'm personally using Patreon.
And that's how we got to know each other.
CodeChip 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.
CodeChip supports your GitHub and Bitbucket projects.
You can get started with CodeChip'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.
All caps, no spaces.
Check them out at CodeChip.com and tell them thanks for sponsoring the show on Twitter where they're at CodeChip.
I was on Twitter complaining like I do sometimes about paying for bandwidth and stuff for my podcast because it's going up.
It's kind of like doubling each month.
And it's, you know, not a huge number now, but doubling a medium-sized number becomes a problem really quick, right?
So I was saying, well, this is getting pretty expensive, OGs.
And a guy, I believe his name is Justin on Twitter, says, hey, why don't you use Patreon?
And that's the first I heard of you guys.
So I'm like, wow, let me go create an account or a campaign on Patreon.
I thought of other ways to kind of do this.
Like maybe Kickstarter might be an answer.
But to me, Kickstarter is the wrong thing because it's like you fund this thing once and there's like a big bang creation.
And that doesn't really work for things like ongoing podcasts or sort of steady state stuff, like you're saying, like web comics or things like XKCD type stuff, right?
Yeah, that's right.
Our goal is that people who want to create things are able to make a living off those creations.
And to do that requires sort of mimicking the structure that I guess like a job sort of has or mimicking the idea of having like ongoing support for your ability to create things.
And I think it's a lot of the reason why I joined Patreon is because I believe in the mission.
And a lot of the people who work here as well also believe in the mission.
I think it's a really great mission.
And it definitely makes having my podcast simpler.
And I just want to say thanks to everyone out there who's contributed to my campaign so far.
And I think what you guys are doing is really great.
So I was super excited about it when I first heard of it.
It just I hadn't heard of it before.
So let's talk about PHP a little bit.
So it was originally written in PHP.
And to be honest, I don't have a ton of experience personally with PHP.
But what are some of the pain points that you're solving with Python?
A lot of organization of code.
I think with namespaces, I think it's just I mean, it's a very simple feature.
But being able to segment our code out into separate modules allows different teams to work on different aspects of the site.
Secondly, with decorators or with like a sort of single points of entry for application.
The way we're currently using Flask and the way the Flask does routing is like through decorators.
And because we're doing everything through this standardized way, if we want to change something like if we want to say start recording response times and graphing that on a chart, we can just do that by modifying decorator rather than trying to input that into each individual PHP script.
Right.
The way they do decorators with what is it?
App.route as a decorator on all the methods that power the views.
Yeah, that's right.
Yeah, that's really cool.
We just had Armin on the show for the previous show.
So people hear more about him.
I'm assuming it's pretty cool.
But yeah, I'm a big fan of Flask.
And you guys said you're doing Python 3, right?
That's right.
That was sort of one of the small risks that we took.
Most of the other technologies that we use are pretty boring or at least like pretty standard like Flask or SQLAlchemy or Jinja 2.
But we decided that we would go with Python 3 going forward because we wanted to make sure that our code base is going to be future proof.
I think that's a really nice choice.
And I see more and more people moving to Python 3.
There's still a lot of folks doing Python 2.
But it just seems a little wrong is not the word I'm looking for.
But it just seems like something is out of balance where there's a lot of people working on Python 3 to push the future of Python.
And then there's so many people who are actually not using it.
Some of the biggest users of Python are not using kind of where the community is focusing its effort.
And so I personally think any time you get a chance to use Python 3 is kind of helping the community move along, let's say.
The way we went about it, actually, we took a look at the wall of superpowers and just saw what are the modules that we need to actually build our application.
Most things that we needed are already implemented.
The one thing that was missing was MySQL DB.
And that was pretty easily replaceable by PyMySQL.
And so it's been actually a really, really simple switch for us.
The biggest sort of hump that we ran into is that, like, Stack Overflow or Google defaults to Python 2.7 in terms of its help.
But it's been a dream for us to work with.
Yeah, that's really great.
So let's see.
You're using Flask.
It sounds like you're using MySQL.
It's the back end.
SQLAlchemy.
SQLAlchemy is really fantastic.
What else are you using?
Any other cool parts of Python or libraries?
Our starting point was just to mimic as much of PHP as possible.
And so in terms of complicated technologies, we actively chose against using any of them.
A lot of really standard modules like requests or Jinja 2.
But nothing too out there yet.
That makes perfect sense.
Let's talk a little bit about the whole porting concept.
Porting your code is basically a rewrite when it's this divergent of a technology, right?
And so that's a pretty big risk.
How did you guys decide that that was the path forward?
Yeah, it was a pretty big risk.
In fact, I've been burned by a lot of ports in the past.
A previous project I've had was porting something from Python to Scala.
And I think that's a much, much more difficult process to go through because you're putting basically a dynamic language into a static language.
And that just adds a lot of weight to the process.
We decided pretty early on that PHP wasn't going to be how we wanted to go forward with engineering.
The decisions we had to make were, like, given the current PHP code base, could we refactor it into something that's more workable using, like, a modern framework?
Should we port it to Python or should we port it to, like, I guess a crazier language like Scala or Java?
We didn't want to, like, the ecosystem of PHP was, we found, much weaker than that of Python.
I think a lot of the main consumers of PHP has mostly revolved around Facebook and a little bit around, like, the Wikimedia Foundation.
But besides that, not a lot of support.
Whereas Python has what feels like a more active developer community, a more active ecosystem.
It lends us a lot more legitimacy for hiring engineers.
It is more consistent of a language.
And it was just different enough from PHP but close enough that, like, we felt comfortable doing a one-to-one translation from PHP to Python.
Right.
It was different, but it wasn't completely alien to make that transformation, huh?
Yeah.
The other option we had with Scala was just too different and, like, too many unknowns.
And when it comes to ports, I think there's usually a pretty high probability that a port will fail.
I've seen a lot of port projects just, like, fail in the past.
And in order to prevent that from happening, I think we as a company decided we want to take as few risks as possible.
Yeah, that makes a lot of sense.
You'd mentioned, like, sort of developer happiness and things like that.
There's a really interesting yearly developer survey by Stack Overflow that comes out, and they sort of rank technologies, what's growing, what are the jobs, what are technologies people love, and what are technologies people strongly dislike, let's say.
It's a concern that they're working with it.
And I think Python was on the list of the beloved technologies, and PHP might have been on the list of the ones to kind of stay away from.
So you think it's easier to hire people because you can say, hey, come work on this cool Python 3 Flask project than it is to say, come work on this PHP project?
When it comes to PHP, PHP has been really easy to develop new things, but it makes it extremely difficult to maintain that code after it's been developed.
And I think that the gains you get with PHP are also seen a lot in Python, but the maintainability of Python is so much greater for us.
Engineers, I think, rank maybe a little bit unfairly, certain languages as more hardcore than others.
I think PHP ranks pretty low.
I think there's a lot of unfair feelings towards PHP, especially since it's been developed and it's been actively used by companies like Facebook.
Yeah, and things like WordPress, right?
And there's some pretty amazing stuff out there.
Yeah.
But there's a lot of parts core to the language, a lot of inconsistencies, a lot of things like global namespacing, a lot of things like having to worry about security or magic quotes or PHP ionized that worked well in the past, but don't really hold up against the modern language.
Sure.
That makes sense.
So you chose Python over the other options that you listed and obviously the ones that you didn't list as well, like over all the other possibilities.
Does that mean that a lot of the people there had lots of Python experience and that's kind of what they wanted to move to?
Or how did you as a group decide?
This episode is brought to you by Hired.
Hired is a two-sided, curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front and you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers in just the first week and there are no obligations ever.
Sounds pretty awesome, doesn't it?
Well, did I mention there's a signing bonus?
Everyone who accepts a job from Hired gets a $2,000 signing 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 $4,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the call.
Yeah.
As a group, we actually have a lot of really disparate skills.
Some in Java, some in Ruby, some in JavaScript, and some only in PHP.
There was no language that everyone was going to be really favored on.
And as a result, we just had to make a decision.
We chose Python because we knew it would be pretty safe.
And we knew that, like, Python is a really easy language to just pick up over a weekend.
Like, it's the tutorial on Python or the way that most people, like, learn Python is usually over a weekend.
Getting the very basics of it are pretty easy.
And getting into the depth is, like, a gradual learning curve.
I think it is a super easy language to learn.
Where the real work is learning all the standard libraries and all the popular packages, right?
Like, really mastering things like SQLAlchemy and Flask.
And, right, that's the real learning curve.
But it's kind of unavoidable.
Yeah, that's totally right.
Nice.
So you guys sort of chose Python because it would more or less make everybody happy.
And it was a really good, safe choice.
I think that's a pretty fair characterization.
I've heard somewhere, I can't remember if it was when I was talking to the guys at PayPal or if I heard it from LinkedIn.
But, you know, as people said, other places that they've chosen Python because it was everybody's second favorite language.
Like, a lot of people really, really like Ruby.
I've also worked with Ruby professionally.
I like it as a language.
But sometimes, like, yeah, we had to pick something that's good for everyone, not necessarily great.
Right.
Somebody's got their pet language that they're super happy about, but, you know, other people dislike it.
And so, yeah, I think Python fits really well in those situations.
What really helped us with Python also or making that decision was that the amount of movement in terms of data science or, like, with, like, SciPy or NumPy has been, like, much greater than a lot of other languages.
And we knew that eventually if we wanted to do sort of like a data-driven approach to our projects or a data-driven approach to our roadmap, that getting our stuff in Python would lead to a lot of – would allow us to hire a lot more data science people or, like, allow them to onboard a lot quicker as well.
Yeah, and crossover as well.
So you might know the whole spectrum even better.
There was a really interesting PyCon presentation from Fernando Perez, the guy who started IPython, at PyCon 2014.
And he talked about how the adoption of Python and IPython and data science is so taking off.
Maybe I'll link to that video in the show notes.
But basically he said, you know, if you look at the technologies used in the stuff that's submitted to Strata, the big data conference, I think, in your town.
And the data he had was basically showing that people used to be doing things like R and to a large degree that's been replaced by IPython, NumPy, SciPy, Matplotlib, all those types of things.
It's really amazing.
So are you guys thinking of using some of those technologies?
You said NumPy for sure.
Yeah, definitely.
As we start bringing on – like, at this stage, we're just collecting a lot of data, like, with our – like, our page views.
But we are pretty comfortable that, like, it's a well-trodden path of putting – or, like, integrating NumPy or, like, Matplotlib into our data once we have someone who's, like, working full-time on data science.
It's a language that I think, like, sort of has, like, broad appeal outside of engineering.
And that's, I think, really important to us.
And I think having the data science component there really is powerful for you guys.
I mean, you've got all these people who are creators, and you've got all these patrons that are supporting them.
And just helping those people align better will just help your business.
And it sounds like big data type stuff would be perfect for that.
Yeah, totally.
Okay.
So you're doing this port to Python on Flask and Python 3, and that's cool.
When did you guys start on it?
We started as of late November in 2014.
Okay.
So at the time of this recording, it's June 2nd, so that sounds about, like, seven, eight months?
Yeah, that's right.
The first thing that we did was just getting to the first page.
I think in our porting process, we wanted to have, like, immediate deliverables and, like, immediately put Python in front of users as soon as possible.
So in terms of, like, the project, we just picked one page, a fairly low-risk page, which is our slash-about page, and just made it our only one goal just to see how fast we could get that page rendering in Python to production.
That's a really interesting way to do it.
So you're kind of taking a vertical slice instead of trying to, like, horizontally going through it.
So you can get some piece of functionality shipped straight away.
It seems like that would help a lot with mitigating the risk of, like, will this port ever be done?
When it goes live, will it ever work?
Things like that, right?
Yeah, that's totally right.
We were really afraid that if we took a horizontal approach, like, we built all the infrastructure around the web framework, we built all the infrastructure around the models, built the infrastructure around controllers, that at some point we would have to just, like, flip a switch.
And that was really scary because there's, like, a lot of risk that we can't necessarily detect with, like, just unit testing or integration testing.
Sometimes we just want things to be as close to production as possible.
And as close to production as possible is sometimes just production.
Yes.
That's pretty close to production.
So you had a pretty interesting approach.
So you started with the something simple, and you're like, let's get this whole thing out there.
How did that go?
You had to get the app written, which is not a really big deal.
But then you had to do kind of DevOps, database stuff.
What was the process?
How smoothly did this go?
Right.
The complicated part here was getting our existing site, which is still running on PHP and Apache, to work well with the Python Flask infrastructure.
And the way we handled that was in Apache, we used a proxy pass on particular routes.
In this case, for the about page, we used proxy pass slash about to our Python backend.
Okay.
And so you could just sort of bypass your main app and send it straight over to whatever WSGI server you got running Flask, right?
Yeah, that's right.
We started up at an entirely different tier using Nginx, Gunicorn, Flask, but pointing to the same data sources.
And we were able to flip a switch just on and off of whether or not we wanted a particular page to go to PHP or to Python.
Wow, that's really cool.
So I guess you just flipped that switch at the proxy pass level.
And it was still living in the original PHP site.
And then you started adding features to the Python version.
And would you flip it on and off to see how it would flip it on for a little bit, see if it's okay, and then flip it back?
What was that like?
We tried to just flip it on and just keep it there.
Although, you know, in terms of like mitigating risk, it is really comfortable to have, to know that you can always flip back and forth between a correct version and like the Python version.
Having this, we also did a lot of things with having the separate architecture.
And so one way we actually did testing was, and this isn't our comprehensive test, but we would open up the site in PHP.
We'd open the site directly by bypassing Apache completely and going directly to our Python infrastructure and just like tabbing back and forth between the two.
And it makes a lot of differences really obvious.
Just kind of a visual diff, if you will, huh?
Yeah, exactly.
That's cool.
So you went through a whole process of like choosing the next page and so on, and we talked a little bit about that before the show.
Can you maybe talk about that?
You start with the About page, and then where do you go from there?
Yeah, so the discipline that we tried or like the process we tried to go by was to start with low traffic, low complexity pages.
And this just let us make sure that our web framework was the way that we wanted it to be, that we wanted like, you know, we could register the correctness of the site without a lot of risk.
And that was like what the About page was about.
Right.
That almost tests your infrastructure more than anything, right?
That everything's hanging together.
Yeah, exactly.
Made sure our proxy password correctly.
Made sure we did session handling correctly.
We just wanted to start with like, you know, rigorously testing like one small thing at a time while we were rolling this out.
Okay, so after About?
So after About, like we, and we were comfortable with, you know, for example, like logged out and logged in traffic being correct.
We started going and just porting to high traffic and low complexity pages.
So the stuff like our index page is pretty low complexity.
It's mostly just featured artists.
Our featured page is also like featured creators in our search page.
This let us make sure that our scalability was in order.
The complexity of this page is like, we didn't have to write a lot of additional code to make those pages correct.
But we did have to like make sure like we need, how many servers do we need in order to support a certain amount of traffic?
How much do we need to like mirror the amount of performance that the PHP side was having in Python?
So performance, that's an interesting question.
Have you noticed a difference in performance?
It's actually slightly faster in Python because we're doing certain things a lot more efficiently.
like we have, you know, one entry point into our DB as opposed to doing like MySQL underscore, MySQL underscore query or like MySQL, like a lot of the MySQL underscore functions in PHP.
That goes along with also cleaning up the code base.
But like certain things with refact, like with making things correct in Python, just had the side effect to make things faster.
Yeah, that's really interesting because it's a simpler language.
You might not, it might be easier to write it correctly or more optimally.
Yeah.
One thing that we did run into was that because the default state of PHP is to just stream all the data as it comes out into standard, like from standard out directly to the client's browser.
And so on the PHP pages, you would see like stuff coming in right away.
With Python, we, we used Jinja2.
And so like we needed an entire template to render before we sent it down to the user.
So we had to do a little bit of a things to make the performance feel as fast in Python as it did in PHP, like using generators instead of like sending down like one large HTML block.
That's really the problem you experienced with almost any of the template, HTML template style things, right?
As you're not streaming directly to the browser, they execute and then send it down.
It's, it's a perception thing, right?
Like it feels slower, even if in the end, the same amount of stuff is on the page in the same time.
Yeah.
Like for example, our creation pages in PHP took six seconds to render, but you didn't feel it because you would still see the, like the embed.
Or you would see like the, the, the becoming a patron flow right away.
And it ended up like the slow part of the page was rendering the comments.
And that was also do like number of inefficient things we were doing with the data fetches.
But when we reported that straight up from PHP to Python, we just wouldn't see a page load for six seconds.
And that's too long.
That's definitely too long on the web.
Yeah.
And so we just like, we implement our own version of like lazy loading and like made sure the comments would come in after all the, the really relevant parts of the page came in.
And we also made some like, I mean, after we got that first part through, we started making some efficiency, like, like optimizations with the performance.
But we decided that like, you know, finishing the thing was first, like finishing the, the, the correctness of the, finishing the correct page was the first thing we'd go for and optimize the data calls later.
Right.
Okay.
Maybe we come back to some of the optimizations, but I'm, one of the questions that's coming to mind is, are you guys done?
Uh, so we are 98% of the way through and, that's not necessarily an ideal situation, but we're about halfway through the project.
We realized that like we could actually start implementing new things on top of the base that we, produced.
So after we implemented the, the user page, the creation page, and, a lot of the other sort of high, like one of the, some of the higher complexity pages with higher traffic, we had most of the models in place that we could start actually building new things.
The first thing we implemented was a, a really simple, feature for migrating, sub-able users from sub-able onto Patreon.
And we've been launching, we've been developing an API service layer for, the, the web client and the, the mobile app to be, to, to be unblocked and allow them to, they, reach some amount of progress.
Uh, where we're stuck right now in terms of the Python port is the long tail of like really low traffic, but like sort of high complexity pages.
So like stuff like, like the settings page or stuff like with, like patron manager.
Yeah.
Are there a bunch of like internal pages that you guys have that are complex dashboards that from the outside we don't really see, but have to be moved over eventually?
Yeah.
We have a lot of internal dashboards.
A lot of them have like a varying complexity.
Um, those are lower priority because we wanted, you know, the production pages to be out first, but eventually those will need to be ported to Python as well.
Yeah.
So at some point you'll want to turn off the PHP site if possible and only manage one thing, right?
Yeah.
Our, like our number one dream, like with the Python port is to be able to completely delete the PHP repo entirely.
And that just means like number one, like the PHP is not running in production, obviously.
But secondly, it means that like the Python reference is what we're going with going forward.
So you're already doing new features on top of Python.
So it's, it's already serving you pretty well.
One of the hard cells with doing a port is that while the port is going on, you can't do a lot of ongoing feature development.
And the product itself will seem to stagnate for a while.
And it has to be like sort of understood from like everyone that like, that's the way it has to happen.
Like it can't do development in PHP and then like sort of backport that into Python later.
It's going to slow down development of both, both systems.
Yeah.
And you guys came out, you said what, 2013?
Yes.
That's May, 2013.
Yeah.
And so if you're going to do this in 2014, you've got a year old product and you're saying, we're not going to change this for six months.
That's kind of crazy in web time.
So you had to do something, right?
Yeah.
It was kind of painful at like trying to sell that at first.
But the idea is like we're going for long-term value and our long-term value depends on like engineering feeling like they're working with a language that makes them happy.
Yeah.
And that's, that's worth a lot, right?
I mean, that means keeping the good developers.
People are excited about their projects.
Like it's, it's really a big deal.
Probably easier to fix bugs as well.
Yeah, definitely.
We use an external service called Rovar that just like lets us identify like, well, any error that happens in production just immediately goes to that service and produces like a stack trace and like, you know, as much information as we can about the request and the headers.
And it just lets us debug really quickly.
What other infrastructure have you put in place?
You guys have like automated tests and stuff like that?
Yeah, we do the simple things like unit testing.
We have a staging environment.
We do some of the more creative things we do is like we have this concept of a walk test where for every page that we, or every route that we implement on the site, we just have a bunch of users of different profiles.
Like we have a dummy patron account or a dummy creator account and just have them load the page.
And that just makes sure that like the page loads with the 200.
It's a really lightweight way of testing if like every code path or like every possible view, every possible viewer of a page will actually render.
But it is like it's a really high leverage test.
It's for the amount of effort.
That's surprisingly effective because if something goes wrong, a lot of times it's a 500.
Yeah, exactly.
It ends up being about like 40 lines of code to actually implement that.
But it catches a surprising amount of bugs.
Yeah.
You don't want people to see 500s on your site.
That doesn't encourage confidence.
The second thing that we did was we did this thing called dark moding, which was while the PHP service was still running or while the PHP website was still running, we would take all the requests for the Python pages that we were reporting.
So like if we were reporting over the slash user page, we would record all the requests that were coming into slash user.
And then we would just replay all of those, all that traffic onto a detached Python instance.
And so before we flip the switch or before we flip the proxy pass from Apache to point slash user at the actual Python backend, we would sort of run dummy traffic through our Python code base with a read only database user.
And just make sure that like no matter, like we would take real traffic and make sure at least that they all rendered.
Wow.
That's pretty cool.
So another super lightweight way to do testing, but you just take all the traffic and you feed it over there.
And again, it had better not return 500 and things like that.
Right.
Like these are the actual types of query string parameters we're seeing.
These are the, you know, the, the route data that's coming in, that kind of stuff.
Right.
Yeah, exactly.
Like this is the cookie.
This is the logged in user.
These are the headers.
A lot of these things were like, we were able to leverage our existing system.
And like, if we didn't have an existing user base, we would have had a harder time with that.
But because we did have an actual live product, it gave us a lot of confidence that when we ship something live, that it would, you know, comfortably stand up to the traffic.
Yeah.
Nice.
Did you have to do anything special for scaling to handle the load?
Surprisingly, no.
A lot of the scalability can be handled, or we found that scalability could be handled nowadays just by ups, like vertically scaling our MySQL instance.
It was kind of a little bit disappointing to me because I really like performance tuning.
But it actually, like we're on AWS and we're on using RDS for our database and it made things like extremely easy.
Right.
And I haven't used RDS on Amazon too much, but that's relational database as a service, right?
And so you can go over there and can you just turn a knob, just say, I need more database and you get it?
Yeah.
If you want to upgrade something from four cores, 16 cores, like basically one switch does it.
Yeah.
The cloud is awesome, isn't it?
Yeah.
Do you guys have it like geo-replicated anywhere or is it in one particular data center?
We haven't replicated across availability zones, but not across regions right now.
Sure.
Okay.
Makes sense.
Are there any special techniques or things you've learned porting PHP to Python?
Any tips and hard-earned things you can share with the listeners?
Well, when it started out, we, so again, we didn't have a lot of Python experience or a lot of like deep Python experience within the company.
So the first thing we had to do was sort of like, or the first thing like I did was try to get people really excited about Python.
And when I started programming in Python, the thing that turned me on like the most to it was Peter Norvig's writing a spelling corrector in 21 lines.
That, and I think like it was a really good sort of like intro to the advanced features of Python or what like sort of canonical Python looks like.
Granted, there are a lot of tricks that like are also used in that that like aren't necessarily the most maintainable, but it's actually, it's a really cool demo.
It's a really cool demo of the language and of like all the features.
Yeah, that's really cool.
And I'll put that in the show links, the norvig.com slash spelling dash corrector dot HTML.
Yeah, I'll put that, I'll put that in the notes.
In terms of like what tricks we use from porting from PHP to Python,
Because people were still picking up Python as they were building out the different ported pages,
we built out a lot of different things to sort of mimic the behavior of PHP in Python, but in a more correct way.
So for example, like the context globals in Flask would mimic the sort of globals that you would see in PHP.
Ternary operators, we just wrote a separate function that mimicked the structure of ternary operators in PHP,
but using a function in Python.
And like whatever we could do to like lower the cognitive load of going from PHP to Python,
made things go like a lot simpler.
Yeah, that makes sense.
That seems like a really good idea.
Did you do anything like PyFlakes or any of the sort of PEP 8 type checking tools to see how people are doing there?
We use, pretty extensively, we use PyCharm inside the company that does the PEP 8 checking for us.
And it's actually, I usually did development, I mean, I've usually done development on just like Vim or Emacs,
but I actually really like PyCharm.
I think it does a pretty good job of things that it wouldn't have caught with a normal text editor.
I can't agree more.
I use PyCharm all the time.
I love PyCharm.
And I used to use Emacs, but it's all about PyCharm for me these days.
You know, if it takes an extra second to load, there's a whole lot more goodness on the other side of that, right?
Yeah, it really saves a lot of time.
Yeah, you know, if it saves you one bug a week, it's probably saved you an immense amount of time.
We're actually going to have the PyCharm guys on the show here pretty soon, so excited about that as well.
Really cool.
Yeah, they're doing good work, and they have a free version.
I don't know if everyone knows, but they've got like a community version and a pro version.
It's pretty affordable, that thing.
The pro version is definitely worth it.
Yeah, it's definitely worth it.
But if you're not convinced, you know, the free version is hard to say, well, I can't try that.
It's too expensive.
Nice.
So overall, you feel like you've made a good choice?
Looking back, you've got eight months of experience.
You've got a running site.
You've had to live with the thing for a while.
What are your thoughts?
Yeah, I think one thing that I do wish is that the site were 100% ported right now.
It would make certain aspects of the operations in architecture much simpler.
But I'm not unhappy, like I'm actually pretty happy with the place that the port is in right now.
I think the number one thing is always going to be developer happiness.
Like if our developers are happy, then that just makes things a lot easier.
Yeah, I think you're totally right.
It's very hard to undervalue enthusiasm.
Being excited about something can really affect the way that you work when you're doing creative things like programming.
And think just like small things like onboarding new users onto Python or new engineers onto Python.
It's much easier because it's a much more consistent language.
PHP has a bunch of really small quirks that are increasingly becoming very specialized knowledge.
A lot of inconsistencies with the standard library.
And very small things are easy to learn, but all these sort of active cognitive load of onboarding to a new language.
And Python has been much, much better with that, especially with Python 3.
Yeah, Python 3 feels pretty cleaned up.
I think that makes a lot of sense.
All right, Albert, I think that might cover it.
Anything else you want to add on this whole adventure you've been on?
Not much.
I think we pretty well covered it.
So, you know, I'm sure there's a lot of people out there with PHP sites that have considered moving to Python.
And I'm sure this conversation will be helpful.
Yes.
I want to reiterate, of course, it was a very, very serious choice for us.
We spent a lot of time, like, thinking about it.
But, like, once we made the decision, or, like, once we decided that that was the right place to go, we just got started right away.
Were people pretty excited once you kind of decided to do it and start going?
I think there was a lot of burnout from PHP, and I think there's a lot of excitement around Python.
So, yes, definitely.
Yeah, very, very cool.
All right, before I let you out of here, there's a couple of questions, one of which you've actually answered already, that I always ask my guests at the end.
One is, what's your favorite PyPI package or sort of thing out there that you want to tell people, like, hey, you should go check out X?
I'll have to think about that.
Like, I don't want to say requests, because I think that's a pretty difficult answer.
Request is pretty amazing.
I learned from the show with Kenneth Wrights that requests have been downloaded 40 million times.
I mean, that's unbelievable to me.
Yeah.
Oh, I think for us, RoeVar has been, like, amazingly good and, like, amazingly easy to set up.
Okay, awesome.
And RoeVar, that's R-O-V-A-R.
R-O-L-L-B-A-R.
And it's, like, I think this is probably the startup that has, like, only a few people working on it, somewhere and so on.
But, like, it just, like, saved us so much time in having to, like, build out a sort of error-detecting infrastructure.
Excellent.
And it's just always watching, always got your back, which seems like a really powerful thing when you're doing a port like this.
And you're just probably a little nervous all the time in the beginning.
Yeah.
It's, like, very, very comprehensive and that, like, you know, maybe a bit noisy, but, like, really gives us a lot of confidence.
Yeah.
That's fantastic.
The other question I always ask is, what's your favorite editor?
But we already had our PyCharm conversation.
Yeah, definitely PyCharm.
I, like, highly recommend.
Yeah.
So, I definitely recommend people go and check out Patreon.
Albert, you guys have done a fantastic job.
And if you're out there creating any sort of thing that has short, multiple release cycles, like, even if you're doing an open source package, it seems like that's something you could create a Patreon campaign about and put up there.
If people want to support it, they can sort of, hey, every time you ship a new version, you know, here's five bucks or something.
Yeah.
We have people supporting creators that do anything from, you know, making YouTube videos to making Dwarf Fortress.
And so, like, we welcome any creator who wants to use us.
That's great.
Yeah, it's been a great experience for me, and I definitely recommend.
If this is the type of thing that would help with your project, then definitely check them out at Patreon.com.
Albert, thanks for being on the show.
It's been great, man.
Yeah, thank you.
Yeah, bye.
This has been another episode of Talk Python to Me.
Today's guest was Albert Hsu, and this episode has been sponsored by CodeChip and Hired.
Thank you guys for supporting the show.
Check out CodeChip at CodeChip.com and thank them on Twitter via at CodeChip.
Don't forget the discount code for listeners.
It's easy.
Talk Python.
All caps, no spaces.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python To Me and get five or more offers with salary and equity right up front
and a special listener signing bonus of $4,000.
Also, don't forget, awesome t-shirts await you at bit.ly slash Python shirt or just visit the website and click on shirt in the footer.
You can find the links from the show at Talk Python To Me.com slash episodes slash show slash 14.
And 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 and direct RSS link feeds in the footer of the website.
This is your host, Michael Kennedy.
Thanks for listening.
Smix, take us out of here.
Stating with my voice.
There's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
First, develop, first, develop, first, develop, first.
First developers, developers, developers, developers.
developers, developers, developers, developers, developers.
you