You've heard that machine intelligence is going to transform our lives any day now.
This is usually presented in a way that's vague and nondescript.
This week, we look at some specific ways machine learning is working for humans.
On Talk Python to Me, you'll meet Patrick Hayes, the CTO of SigOpt,
whose goal is to accelerate machine learning by optimizing everything.
That's a pretty awesome goal.
Listen in to this episode and learn all about it.
It's episode number 51, recorded March 3rd, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python,
the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
A couple of quick updates for you before we get to the interview with Patrick.
First, I want to thank all of you who participated in helping me launch Talk Python training through Kickstarter.
I finished the course, got the website online.
It's training.talkpython.fm, and added all the Kickstarter backers who have filled out the survey to the course.
The feedback so far has been really positive.
I got this from one student just today.
Absolutely loving the course.
I learned so much, not just Python principles, but your methodology with designing an app.
Your lessons in PyCharm have really helped a ton, too.
I've bought so many books and online classes, but nothing has brought it all together like you have.
So a big thanks to you, Michael.
To celebrate the launch of my course, I'm giving away a free seat to a friend of the show.
Just enter your email on talkpython.fm to be eligible to win.
I'll draw a winner at the end of the week.
Next, I had the honor of telling the story of my career, how I went from super junior,
know-nothing developer to developmenter instructor to owning my own business and launching the show.
I was on Developer on Fire podcast last week.
If you understood these kinds of stories, check out Dave Reel's podcast at developeronfire.com.
My episode was 112.
Now, let's get to this interview with Patrick.
Patrick, welcome to the show.
Thanks, Michael.
Yeah, it's super exciting you're here.
I'm ready to optimize everything.
Perfect.
That's what we're here for.
Very cool.
Now, before we optimize everything, let's start at the beginning.
What's your story?
How did you get into programming?
Sure.
So I started when I was a kid.
You know, I was young.
My parents' computer played around in Visual Basic or Java or things like that.
Kind of just playing around, making little toys myself.
They sent me to computer camp at one point, and that's really where I started to get excited about it.
Then I went to the University of Waterloo, where I studied computer science.
And there, of course, where I got, you know, much better fundamentals and started, you know, to build my career from there.
And then I started with Python on one of my first internships.
So I was an intern at BlackBerry, and this was probably back in 2007.
And at that point, my, you know, programming experience, I was still pretty junior.
And I was used to Java and these kind of very verbose languages.
And then one of my previous colleagues had written the script in Python, and it was one of my tasks was to update it.
So I got in there, and I started playing with it, and I realized, oh, actually, it's Python stuff.
Pretty cool.
It's much, you know, I can be more expressive, and I can work more quickly.
And that's when I started to become a big fan, and I've used it in most of my personal projects since.
A lot of people who don't work in Python have this sense that it's kind of like Bash, but you can make websites with it.
Right.
You know, they don't see the entire sort of landscape of all the amazing stuff you can do.
And so a lot of us, when we come to you, you're like, oh, there's a little script I got to maintain.
Oh, my goodness.
Look, there's this thing called PyPI.
And oh, my gosh, look what else you can do.
Exactly.
That's awesome.
Increase in productivity, you know, it was kind of like night and day from what I was used to.
So that's definitely.
So what did you study in college and work on in BlackBerry?
I studied mathematics in university.
So I did computer science and also pure mathematics.
Yeah, cool.
So I went to University of Waterloo.
And then while you're at Waterloo, you do six internships.
So I was at BlackBerry for my first one.
And there I was working on the automated testing team.
So, you know, one of the things.
Oh, that's a cool.
Yeah, it was, you know, I was just getting started kind of with my very first internship.
So it was a good way to get my feet wet.
I think it's cool that university has the sixth internship.
Yeah.
Because a lot of times you come out of college and you're like, okay, now what?
Yeah, it makes a huge difference.
Definitely.
I felt that in my career.
You know, you graduate and you have six, four month internships.
So you basically have almost two full years of work experience at this point.
So it's really kind of night and day versus if you hadn't done these internships, what kind of experience, practical experience you have.
And it really does complement the education well.
Because what you learn in class is very kind of theoretic and good fundamentals.
Yeah, it's somewhat detached some of the time.
Yeah, exactly.
But then when you get into the real, the industry, you're really learning totally different things that you, and you need both to be a good engineer in this day and age.
Right, of course.
So the company that you guys founded, SigOpt, has machine learning as its sort of central feature that it provides, right?
And so could you tell everybody a little bit about just, you know, the mechanics of machine learning and describe how some of the pieces work?
Just so, before we get into the details.
How machine learning works?
Well, yeah.
So let's just take a concrete example, right?
Suppose I've got some data about a bunch of shoppers and I've got a store and I'd like to optimize something.
You know, give me a sort of how you'd go through that with machine learning.
Yeah, sure.
So a great example, if you have a store, would be you might want to predict fraud.
But if you have, you know, much of purchaser, historical purchase data, and maybe you want to minimize the number of fraudulent purchases you receive.
Because that's, you know, affects your bottom line.
Every kind of, every fraud, fraudulent purchase costs you money.
The problem that machine learning can help you solve is, given that you have all this historic data that you've built up over the years, how can you use that to, in the future, make predictions about events you haven't seen yet?
So if I've seen a million purchases in the past, I know things about those purchases.
Like I know the country that it came from.
I know how much money the purchase was for.
Whether it was from a sketchy IP address or something like that.
And I also know the truth you need to learn from, which was that purchase fraudulent or not.
And now you have this data set of past truth, and then you can apply machine learning methods on that data to produce a model that will make predictions in the future.
Okay.
So basically, as people are checking out, you can ask, hey, should I let this go through, even though the credit card system said yes, right?
Exactly.
So even though you don't know for sure yet whether it is fraudulent, you can make a guess, a good guess, based on the data you've seen.
A good machine learning model, you know, will be accurate, as accurate as possible.
You'll always have sort of false negatives and false positives.
So, you know, saying a purchase is fraudulent when it might not be, or vice versa, thinking a fraudulent purchase is okay when it is fraudulent.
But you want to, of course, minimize that.
And a good machine learning model and machine learning process will reduce that.
Let's talk about SigOpt a little bit.
Your theme or your tagline is to help customers optimize everything.
You got it.
That's a pretty audacious goal.
What is this company you guys founded?
So SigOpt is a SaaS optimization platform that helps companies build better machine learning models with less trial and error.
So we have an API that exposes the most cutting edge optimization research to our users to help them increase the accuracy of their machine learning models as quickly as possible.
So in this example of a fraudulent, a fraud detector, our APIs would help them tune that model to make, to really reduce that, those cases where it would be inaccurate.
And we want to get our users to these most accurate models as quickly as possible.
We don't want them to spend days or weeks or months trying different possibilities kind of in the dark.
All right.
That makes sense.
It sounds like a big challenge, but it makes sense.
So you said you're a SaaS company.
Do you actually run the machine learning algorithms?
Do you provide like the compute and data processing?
Or do you somehow just provide, hey, you should feed these inputs to scikit-learn along with your data?
Yeah, that's a great question.
The way we help our customers is they have their own models that they're running on their own clusters with their own data.
So we're not actually running the models for them.
And we're also not looking at any of their sensitive data.
What we're doing is we're having our APIs are able to suggest what's the next version of your model you should try.
So the models have parameters or variables that affect how well the model works.
And finding the best version, the best values for those parameters is a very tough problem.
And that's what SIGUP solves in the most efficient way possible.
Okay.
That's really interesting.
Where did this idea for this company come from?
Yeah.
My co-founder, Scott, he was doing a lot of research on this field during his PhD at Cornell.
So he was doing a lot of research in this field and had this great idea for how to build this kind of black box optimizer.
That was the beginning of that idea.
And we've built the company around it now to put an API around it to make it really easy to use,
to administrate all the difficult computation that is required to serve these optimal suggestions.
Okay.
Do you have some interesting stories around stuff that you've helped people optimize?
I heard one of them was something like shaving cream and another was synthetic rhinoceros horns.
It's quite varied, right?
Exactly correct.
So the optimization, so I've been talking about machine learning here, but really it's actually able to optimize.
Any problem in which trying something new is very expensive because we want to get you to the best version of your product in as few tries as possible.
So that is true for a machine learning model that you have to train it or test it on real user traffic.
And that's very expensive.
But another thing that's very expensive is these chemical processes.
So we have one customer who makes shaving cream and the expensive part for him is he has to go into the lab,
mix up his ingredients into a jar or vat or something, wait for 100 hours for it to settle,
and then test the quality of the shaving cream.
And then based on that, he wants to find a shaving cream that makes him the most profit.
So in this case, there's however many ingredients that go in the shaving cream and mixing them in different amounts is a very chaotic process.
So as a chemist, he's an expert in his field.
So he's able to say, oh, the ranges should probably be somewhere.
This acid should probably be between five milliliters and seven milliliters.
But then at some point, he gets to this area where the knowledge, he doesn't have as much knowledge as possible about the interactions.
So this is where Seagat comes in.
Right.
It gets down to actual experimentation rather than theory, right?
Yeah.
Trial and error.
So now SigOpt, what we're able to do is we're able to model these chaotic effects and are able to suggest,
here's the next version of your shaving cream you should try.
So then he goes back in the lab, mixes up a batch with what we suggested, tells us how well it did,
and then we use that to update our model and give another best suggestion.
So before using SigOpt, this chemist had mixed up, you know, 100 different trials just by like keeping track of it in his lab notebook.
It hadn't really gotten anywhere.
But then he uploaded all his data to SigOpt, and now SigOpt is able to take in that data and analyze it and say, hey, here's what you should try next.
And then he did that.
And then within just five new batches, he already had a new version of his shaving cream that was 20% more profitable.
Wow.
That's really cool.
And you're modeling physical stuff.
It's not just like you're taking in a bunch of data and you're processing it.
Like you're helping this guy, you know, make shaving cream.
Yeah, exactly.
In this case, it's helping with this very physical world problem.
And you also mentioned this.
You're right.
There's another customer using us for synthetic rhinoceros horns.
And this is the same thing.
It's, you know, they want to make a rhino horn that has these properties, and there's various variables that go into that.
Like how much of different chemicals do you use?
And we're helping them with that process as well.
That's cool.
I have to ask.
Like, why do they want a synthetic rhinoceros horn?
It's a great question.
My understanding is there's a large black market for rhinoceros horns.
There's two things at play here.
One is they want to reduce that black market because they want to stop poaching of rhinos.
And one way to do that is to flood the market with these synthetic horns.
So right now, you actually, my understanding is you can sell these synthetic horns for a very high price because they mimic the not very expensive real rhino horns.
But if you can, but the synthetic ones can be produced at a much larger scale.
So now the market's flooded with horns that are identical chemically, but much cheaper to produce.
And now it's no longer profitable to actually poach a rhino.
That's a really good thing for everyone.
That's awesome.
What other sort of stories do you have about what you've helped people optimize?
Yeah.
We also have customers doing synthetic egg whites, music recommendation models.
There's really, it's going to be applied across the board on all these very black box, difficult problems.
Yeah.
Okay.
One of the things I think is pretty awesome is some of the stuff at the heart of what you're doing is actually open source software, right?
That's correct.
Some of the algorithms and whatnot.
And yet you're building a business on top of it.
And I've talked to a couple of companies lately, a show that's about to come out next week.
It's got a really cool sort of story of taking something open source and turn it into a business.
And I want to dig into that.
But one of the places you guys started was at Y Combinator, right?
Yeah, that's correct.
What was it like being at YC?
It was a lot of fun.
It was very kind of exciting, very, definitely a lot of emotions.
You have a lot of fun, but you also have a lot of, you know, stress and you have a lot of, you're very busy.
You learn a lot.
So it was a really fantastic experience.
You know, I think it took what me and my co-founder, when we started, you know, didn't really know much of anything about how to build or run a business.
And just the three months of the first three months of the Y Combinator, you, it's very transformative.
You know what to think about and what not to think about.
You know how to stay focused.
You know how to talk to users and build something that your customers want.
And then it culminates in demo day.
And that's when you present to a bunch of angel investors.
And that's when it really starts your company from there, getting the fundraising you need.
So it definitely makes a huge difference.
We definitely wouldn't be where we are today if we hadn't gone through Y Combinator.
That's awesome.
So how do you actually get into Y Combinator?
Is there like a call for applications?
Yep.
Are there like open demos?
Like what's the story?
Like how would someone out there is listening?
Like I want to be part of Y Combinator.
What do they do?
They may have changed it a little bit since I did it.
So this was I applied in 2014.
But essentially, yeah, twice a year they have an open call for applications.
And they say, what are you building?
Who are you building with?
Send us an application.
They ask you, do you have any customers?
Do you have any traction?
Do you have any revenue?
What have you built so far?
And then they also ask a lot of questions about you as the founders.
They ask, what have you built in the past?
Where have you worked?
One of the kind of notable questions they ask is, what's a system you've hacked in the past?
So not hacking in the kind of infiltrating server sense, but like what's the kind of creative thing you've did in the past to skirt around some, I shouldn't say rules, but not like breaking the rules, but doing something clever or creative in the past.
Yeah, that's really cool.
Would you recommend other people go in there and try it?
Like you found it to be a pretty positive experience?
Yeah, I would say it was positive.
And I mean, I can't say I can recommend it for everyone.
I don't know everyone's specific situation, but I would recommend it definitely.
It really did take, yeah, me and my co-founder from a state of no experience to, you know, competent at building a company in a very short time.
Yeah, I think one of the challenges of starting a company, especially technical companies, the founders, they're technical, right?
And part of starting a company, especially one like yours that is a highly technical science, math sort of company requires that.
But that's not enough for like user growth and business deals and marketing and growth hacking and connections.
Absolutely.
That's a real big challenge.
And YC helps with that, right?
So both me and my co-founder were technical co-founders.
So we had to pick up a lot of skills that we had no experience with.
What I commonly say is before working at Stigop, my last job, I got to work on what I was good at every day.
I was an engineer and I worked on engineering problems.
Now as a co-founder, I work on things I'm bad at every day, which is very different.
You're spending more time, you know, trying to get customers or build a company or think about culture or think about hiring or think about marketing or think about sales.
All these things that I had no experience with prior to starting the company.
So you definitely get a lot of experience with these things.
Yeah, exposure to totally new things, which as you're right, are essential to running a successful business.
But you kind of have to learn it on the fly.
So Y Combinator, they do prepare you for this.
Also, the network is really, really helpful.
So there's probably over a thousand people in the Y Combinator network at this point, you know, past founders.
And it's very friendly and welcoming community.
You can message them if you have any advice or you have questions or things like that.
Oh, yeah.
That sounds super helpful.
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.
When you got through with Demo Day, I saw that you guys actually had two seed rounds.
One for like $120,000 and one for $2 million.
Congratulations on that.
Thank you.
That's pretty exciting, right?
Was that first part sort of the end of YC?
Yeah, the first part is from Y Combinator.
And then at the end of Y Combinator, there's Demo Day.
And that's when we raised our larger round.
And that was to get us, you know, over the next, yeah, get started from there.
Yeah.
So what's it like taking VC money?
That's another skill that you don't have any exposure to before starting a company, or at least I didn't.
So yeah, fundraising is a very kind of interesting beast.
You have to have your pitch ready, and you spend a lot of time talking to investors, and you're dealing with rejection, and also, yeah, communicating in this way that you're not used to this very, yeah, salesy way.
Yeah, you have to have a very crisp message, right?
But it's also different from selling to customers, right?
You're, you know, for customers, you're talking about what's their immediate needs, and how can I satisfy them now?
And when talking to VCs, you're talking about, oh, what's kind of the grand vision of what's the app going to look like in 10, 20 years?
What's the, how big could we possibly be?
Yeah, the customer wants to know, how are you going to help me make my store or chemical process better?
The VCs want to know how you're going to reach, like, large-scale growth and continue user acquisition.
Like, the customer doesn't care at all about that, right?
Exactly.
It's good, you know, talking to investors, you know, and they can really, they can be a lot of help.
They can give you a lot of great resources, especially if you get good investors, which we were very fortunate enough to do.
Another set of connections and network, almost as much as anything, right?
Cool.
So you guys started in November 2014, right?
That's correct.
And you started with Python from day one.
What was the reaction with NYC for using Python?
They give you a lot of autonomy to build what you want, so I don't think that anyone else really would have cared what we built it in.
But it made a lot of sense for us as a company, you know.
So both me and my co-founder knew Python, but I also could tell that this is, you know, would be really great for getting it started and moving quickly.
So especially when we have this kind of short timeline of three months to get out the door before demo day, what can we use to really make sure?
As productive as possible right from day one.
And so Python was a pretty natural choice.
Yeah, I guess, especially in the sort of accelerator type scenario, speed to market is more important than CPU cycles.
Exactly.
Or memory usage or whatever.
Yeah.
But you guys are sticking with it, right?
You've been going strong.
Yeah, exactly.
So we have, yeah, almost everything is in Python.
We have some of our, we have some things in C++ for some very high end optimization that needs to be very performant.
And we use, you know, Python and C++ bindings for that to interact with the rest of our stack.
We also, you know, we have JavaScript, of course, because we have a website as well.
But everything back end is Python.
Okay.
That's cool.
And is that Python 2 or Python 3?
We are Python 2.
Okay.
Right on.
And you said you had considered maybe using Go or Scala or some other languages.
Can you just sort of discuss those trade-offs?
Sure.
So I definitely, I had some experience with both of those.
I think Scala is really nice when I did use it.
It's very safe.
The type safety is really good.
But it's very, it's still very expressive, much more expressive than Java or something, which it's based off of.
And that's really nice.
I think I would be less confident we could move as quickly as we could with Python there.
You can be very expressive, but there's a lot of kind of tooling issues, like the compile times can be very slow.
And also, it's perhaps not as well known.
So you spend some amount of time training new hires or other people to use Scala as well.
And I don't think that's necessarily a bad investment to make always.
But when we were at this stage where we want to move very quickly, then we should stick with something that we can be confident about that in.
And then I had a similar opinion about Go, which is like that was a great language and really has all nice features.
But at the time, I believe it was still, you know, less mature than it is today.
I recall wanting to use an AWS library.
And for Go, there wasn't one at the time.
I think there is now.
But Python, of course, had a great AWS library just ready to go.
So those little decisions of just like, I want to spend my time working on the core business and not tooling and not, you know, building third-party packages, which could already exist.
Right.
There's zero business benefit in you building a Go implementation of Bodo or whatever, right?
Exactly.
So I definitely think, you know, there's lots of trade-offs to be made.
And that's kind of where we were leaning at that time.
And I'm really happy with it now.
So I think it's, you know, we've definitely, we've built a lot.
And I don't think we'd be where we are today if we had perhaps started with a different language.
Sure.
So how much does SciPy and NumPy and all those pieces sort of play into this?
Was that like pretty critical to making it work?
Yeah.
So we use a lot of that for kind of, yeah, high capacity computation and optimization.
They're, you know, really great tools for that, that we love, both in the kind of prototyping phase where we want to try something new on some data set or something like that.
Using SciPy, Scikit-Learn, NumPy are fantastic.
And then also, you know, they have the performance we need to actually put them in production when we're appropriate.
So we also have, of course, things that we built ourselves that are very well tuned to our own problem.
And as I mentioned before, typically those are in C++.
But having this wide array of tools available to us in Python is essential.
Cool.
And I heard you say AWS in there.
Is that where you guys are hosting your SaaS product?
Yeah, that's correct.
Okay.
Are you doing like multiple data centers and things like this?
Or is it US East one?
US West.
Yeah.
So we're still, yeah, there's lots, I would say we're still pretty small.
So there's lots of, there's lots of improvement to do in a lot of fields.
But specifically, yeah, we're AWS is, we're big fans of it.
Okay, cool.
Yeah.
So am I.
Gone are the days of tweaking your server, merging your code, and just hoping it works in your production environment.
With SnapCI's cloud-based, hosted, continuous delivery tool, you simply do a get push, and they auto-detect and run all the necessary tests through their multi-stage pipelines.
Something fails?
You can even debug it directly in the browser.
With a one-click deployment that you can do from your desk or from 30,000 feet in the air, Snap offers flexibility and ease of mind.
Imagine all the time you'll save.
Thanks, SnapCI, for sponsoring this episode by trying them for free at snap.ci slash talkpython.
You guys have to really focus on API design because that's one of the primary ways that people interact with your entire business as a SaaS product.
How do you guys think about that?
Yeah.
Using optimization tools like SciPy or like the open source or other open source optimization tools, one of the problems with them is that they're very, very difficult to use for a lot of reasons.
One of them is, you know, the API might be, you know, very obtuse or not very well optimized to your problem or things like that.
Another problem is administration.
You have to have the servers and set them up and you have to know what kind of capacity you need to optimize your problem.
Like if you use machines that are too small, then it will be very slow and so on.
Right.
But if you bit too many, you're just going to waste money on big machines doing nothing, right?
So what we wanted to do was we wanted to make sure that we can take, you know, this very valuable tool, this optimization tool and really make it what's the easiest possible way to expose it to our customers.
And so for that reason, it's one of our top priorities is having an API that's very, very clean, very predictable, very easy to use, does what you want, a small number of endpoints.
You're not having to, you know, dig into the nitty gritty.
You're not tweaking flags in our optimization.
You're just saying, here's my problem.
Tell me what to do next.
Right.
Do you really try to optimize for the simple getting started case and then provide additional features as needed or how do you do that?
We want to make sure that, yeah, getting started is as easy as possible.
So if you have your problem, you can use our API to define your problem and say, here are the parameters that I'm searching over.
You can also use our API to say, here's what I've tried so far.
And then our API will tell you, here's what to try next.
So it's this very simple, like three calls, one to get started and then one to ask for a suggestion and one to report an observation.
And that's really all a user needs to get started with SigOpt.
And then to the extent that there are, you know, expert level flags, like if you really know that you want this particular optimization thing, we want to make sure it's possible.
But we really don't want it to be users to have to know about it or have to be confused by it just to get access to the really powerful tooling inside SigOpt.
Yeah, that seems like it's keeping with your overall mission of democratizing this machine learning and optimization in general, right?
Yeah.
Very, very cool.
So let's talk a little bit about the open source engine that's kind of at the heart of a lot of what you're doing.
So your co-founder, Scott, he used to be at Yelp.
Is that right?
Yes, that's correct.
Yeah, he worked on this thing called metric optimization engine or Moe.
Yeah, that's right.
Okay.
And so this is sort of one of the core components of your system, right?
Yeah, so we definitely have, we've built more on top of it.
And, you know, SigOpt these days is powered by like an ensemble of multiple optimization methods.
But how we got started from the very beginning was this, yeah, this Moe that Scott had built using his expertise in the field.
And that was the first prototype for can this black box optimization really be, can it be profitable?
Can it be easy to use?
Can it be something that people would want to want to interact with?
And so Moe was the first prototype for that.
And, you know, Moe was very well received on GitHub.
Lots of companies and individuals were using it.
And then some of the very common feedback was, oh, but it's really hard to use.
Or, oh, perhaps it doesn't work.
And then the reason it didn't work was because this one flag wasn't set.
So he and I knew and could see that there's real, real value here.
But the biggest problem is how can it be even easier to use so that companies of any size can have access to this really, really powerful stuff.
Yeah, that's great.
There's this opportunity.
You've got this great open source tool, but you want to build a business.
Can you kind of take me through the thinking of like, all right, we're still giving away this thing for free.
And yet we need, you know, to make something special that customers will buy and love.
What was the thought process?
Just that it's too hard.
How can we make it not so hard and accessible?
Yeah, I would say that's, yeah, the biggest barrier to using Moe is that it's very hard to use.
I think if people still want to use Moe, then they can, but they're going to have a lot of headaches with it.
Our goal is that we want to be the people who remove those headaches.
But as I said, so we kind of, we started with Moe.
And now, in addition to that, we have a wide variety of other optimization methods that we've built in-house.
Those are not open source.
So using Cigar does also give you this kind of wider array of benefits, other techniques, other optimization, kind of cutting edge research.
But you're right that like this, it is still open source.
It is still available.
And like it is still good for the community to have access to this open source stuff to kind of, you know, they can see where we're coming from and what's been built and the kind of background behind it.
Yeah, I think there's a bunch of stories that are coming out of people building really amazing businesses on top of things that they're giving away.
And I think that's becoming much more common.
But still, I think it's really special to see examples of it in action.
Like with you guys, recently I spoke to the Scraping Hub guys that took Scrapey and turned that into kind of a SaaS platform, you know, web scraping as a platform, if you will.
You know, then there's like more obvious examples like MongoDB, Red Hat.
But it's really cool to see you guys sort of turning this into a business starting from this sort of kernel of open source.
Do you still make a lot of contributions to Mo or are there a lot of other people working on it?
What's the story there?
Some people work on it.
Some individuals kind of like in the open source community have been contributing to it.
These days, our contributions are mostly focused on these other methods that we kind of have diagnosed.
Like we're able to diagnose like these are the problems that Mo worked well for.
And then these are the problems that Mo doesn't work well for.
And then how can we as a company attack those and help our customers who have those kinds of problems?
And so we spend a lot of time focusing on that.
And that's sort of perhaps tangential to the public Mo.
So we're still working on that.
At this time, that's still closed source to SIGopt.
Right.
Of course, you got to keep the secret sauce a little bit secret, right?
Awesome.
So can you talk a little bit about how some of the internal systems work?
We talked about your deployments being on AWS, but is there like interesting architecture that you might want to talk about?
Sure. So we have our web and API.
That's, as I mentioned before, all Python.
We use Flask in production to do kind of web serving.
For the most part, we have like our API, which is a very thin layer that just accepts, you know, API requests from our customers of the form I said before where they're describing their problem.
But then most of the work we do is we offload that asynchronously to these high capacity compute machines that are doing the optimization.
So for these problems that are very expensive, we want to be able to, you know, run SciPy or these custom C++ algorithms that we're working on.
Okay. Yeah. Of course, you definitely want to buy the highest end compute machine you can.
It seems to make a really big difference.
If you sort of double your VM and AWS, it seems like the low end is really low.
Yeah.
Yeah. It's great. You have this kind of flexibility to split up your architecture that way for these machines that don't need it and machines that do.
Right. Do you, I mean, that's part of the beauty of the cloud, right? Like it's a checkbox or an API call.
Are you guys doing anything with GPUs given how computational this is?
We do. We have experimented with that in the past, definitely. Like for some of these algorithms, which are, can be really parallelized over GPUs.
That's still something we're working on and experimenting with to see if it's worth productionizing.
Cool. So maybe you could just like in a few sentences, tell people like, what's the deal with like computation and GPUs? Like enough for graphics.
Yeah. So I'll be honest and say that this is not one of my deep areas of expertise.
But my understanding is that your GPUs, you know, they're very highly optimized for this widely parallel computation.
So definitely when you're doing these kind of expensive CPU bound optimization techniques, then you can use GPUs to get those done as quick as possible.
Yeah. Yeah. It's pretty amazing when you look at it. I mean, when I first heard about it, I was like, really? What?
Or doing like math on the GPU? I mean, of course, if you look at video games.
Yeah. Like for a while I worked on 3D simulators and the amount of computation those graphics cards do just to render a scene is mind boggling for one scene.
And then they do it like 60 or 100 times a second. It's crazy.
And that was, you know, so long ago, many years ago that I was doing that. I was still super impressed.
If you look at the parallels, I'm like, I've got a MacBook Pro Retina and it's got a pretty high end CPU, which I think has four real cores and each one is hyper threaded.
So it looks like eight.
But some of those graphics cards have like over a thousand cores. So trying to decide between eight and a thousand for parallels.
Wow.
Yeah. It makes a big difference.
That's pretty insane. So, yeah. I remember a few years ago I saw on AWS as one of the machine types, like a clustered GPU thing.
What is that doing in the cloud?
But yeah. Yeah. Very cool.
So you said you experimented with it. Is it looking promising or?
I mean, so far so good. Yeah. It's definitely seems like something we might might want to go forward with.
Yeah. I haven't really tried this computational stuff with it. There's some really interesting projects, but I just haven't had a use for that much computation, I guess.
But it seems like if you find a case where it works, it works crazy good.
Definitely.
But it's not like a general computer, right? You can't just give it any problem. So there's certain types of problems that are really appropriate or algorithms and certain ones that aren't. So I guess, you know, that's kind of a big decision, whether it makes sense or not. Right.
We're getting kind of near the end of the show. Let me ask you a few questions I ask all my guests. When you're going to write some Python code, what editor do you open up?
I use Vim. I've been using Vim, yeah, for about eight years now. I think I'm, you know, got it pretty well optimized. I feel more productive in that than just about anything else. So that's what I use for just about everything.
Yeah. Very cool. You know, it's very unscientific. Maybe I could pass a few data points off to your system and ask it. But I would say I think Vim seems to be winning the popularity battle among my guests anyway. I'm not sure if they're representative or not at the overall community. But yeah, very, very cool.
And, you know, PyPI has 75,000 packages. Now, just it's insane. You know, how many things are out there that you can just grab and bring into your apps in Python?
What ones would you recommend or what are really important things people should know about?
I would be self-serving and say the SigOps API client Python package.
Ones that I use in my own personal day to day. Definitely IPython. I get a huge amount of value out of just for the REPL and using IPython notebooks.
Like increasing productivity over the regular REPL is kind of astounding.
This is obviously a pretty common one, but I think requests, that's just like, it's become such a necessary part of my toolkit.
Feel shocking that it's not part of the standard library at this point.
Yeah, that's a really interesting comment. I agree that requests absolutely should be up there. It's the most popular package on PyPI.
Oh, is it?
By the way.
I believe it.
Yeah, it's so clean and so useful. And I was talking to Kenneth Wright. He was on the show.
And it was the creator. He was saying they were considering making requests part of the standard library.
But they decided not to because they wanted to be able to rev the features and security fixes and various things of requests faster than they do Python itself.
So they decided to keep it separate, but to make it the recommendation to basically not recommend using URL lib, things like that.
Go, no, no. pip install requests. This is how we do it.
Let's just all agree on that.
But yeah, that's pretty interesting, right?
They actually considered making it part of Python, but for versioning and agility.
Well, it makes a lot of sense.
Yeah, yeah, yeah. They decided not to.
Okay, awesome. If people want to get started with SigOpt, what do they do? How do they get started?
Head over to sigopt.com, sign up, you get started. We have a free trial.
And if you have any of these problems, whether it's a machine learning model that you want to make more accurate or some other kind of process that you're trying to optimize,
you just sign up, get started with our API, and you're off the races.
Okay, that sounds great. Yeah. So pip install SigOpt, sign up, off you go, right?
You got it.
All right, Patrick. It's been great having you on the show. This is really interesting.
You guys are doing some cool stuff and continue to optimize everything.
All right, we will. Thanks, Michael.
All right. See you later.
This has been another episode of Talk Python to Me.
Today's guest was Patrick Hayes, and this episode has been sponsored by Hired and SnapCI.
Thank you guys for supporting the show.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to me to get five more offers with salary and equity presented right up front,
and a special listener signing bonus at $2,000.
SnapCI is modern continuous integration and delivery.
Build, test, and deploy your code directly from GitHub, all on your browser with debugging, Docker, and parallelism included.
Try them for free at Snap.CI slash Talk Python.
Are you or a colleague trying to learn Python?
Have you tried boring books and videos that just cover a topic point by point?
Check out my online course, Python Jumpstart by Building 10 Apps, at training.talkpython.fm,
for a different take on learning Python.
You can find the links from today's show at talkpython.fm/episodes slash show slash 51.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python, which will be right at the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much 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.
On first developers, developers, developers, developers.
On first developers, developers.
On first developers, developers, developers.
developers.
you
Bye.
you