I'm sure you've heard of a full stack developer and full stack Python, but this week Authentize
is taking it to a whole new level with Python all the way from the cloud to the client to
the printer.
It's all about 3D printing with Python on show number 23 with Eli Ribble, recorded Wednesday,
August 5th, 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.
Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter
via at talkpython.
This episode is brought to you by Hired and Codeship.
Thank them on Twitter for supporting the show where they're at hired underscore HQ and at
Codeship.
I don't have any particular news this week, so let's get right to the show with Eli.
Eli Ribble has been hacking since he was little and discovered BASIC, NetHack, and
Debuggers.
He's enchanted by magic, is implemented via technology, and holds a master's degree in
computer science from the University of Utah.
He's developed driving simulator engines, mobile device management on Windows CE, websites, and
various cloud streaming applications.
Recently, he's been building 3D printing technology in the cloud to help start the digital manufacturing
age as the CTO of Authentize.
He's been doing professional Python development for the past seven years.
Eli, welcome to the show.
Thanks.
It's great to be here.
Yeah.
I'm really excited to talk to you guys about 3D printing and Python.
It sounds like you're doing some amazing stuff over there.
Yeah.
Thanks.
We're actually really enjoying it.
I feel like 3D printing is poised to really change a lot of things in the world about how
manufacturing is done.
And it's a lot of fun to get to be a part of that.
Yeah.
I'm sure it is.
It's definitely cutting edge.
All right.
So you work at a place called Authentize.
And you're using Python there.
What's the story with that place?
I actually long ago started the company with mostly contractors doing a lot of development
work.
And they basically brought whatever tooling they wanted to the table.
We had a little bit of Perl, some C, bits and pieces of Python, and a bunch of other languages
I won't go into.
And part of my job here was to bring all of that together, tighten it up, build an engineering
team around, ideally, some reasonable common decisions.
I tend to agree with Netflix's attitude about allowing developers to have some freedom.
But in our space, in 3D printing, Python is extremely common.
And it's also very good for building web APIs and that sort of thing.
And so we use Python all up and down the stack.
We have a desktop client that it's also sort of an agent that manages the printer, sends
commands to it, gets responses back.
That then streams data up to a streaming server that lives in the cloud in a data center.
That's written in Python as well.
We have various APIs where people can send commands to printers, control prints, do slicing, things
like that.
All of those APIs are all written in Python.
They interface with databases using Python.
We manage our deployments even, all with Python.
We are essentially a full Python shop.
Everything here.
Our whole cloud, everything.
That's awesome.
You know, there's the term full stack Python and things like that, which is awesome.
But this is like taking it to a whole nother level.
Like physical objects come out of your full stack Python system.
It's great.
So before we get into that, maybe we could just sort of start at the beginning and talk
about how you got into programming and kind of tell your story.
And then we'll talk about how you guys are using Python.
Gosh, as far as how I got into programming, it was forever ago.
My parents bought an old 486.
My older brother.
SX or DX?
Oh gosh, I couldn't even tell you.
I was not old enough to really care.
It was just magic to me.
That was good enough.
I watched my older brother use it a little bit and got kind of curious.
And here in Utah, we have year-round school.
So you're on again, off again every nine weeks or so.
And during the off times, it was basically me and the computer.
So I started learning basic, doing that sort of thing.
When I got into middle school, they had a class where you would learn the 12-key calculator.
You'd learn basic typing skills, Microsoft Word, that sort of thing.
And if you finished everything in time, there was a little programming module at the end based
on whatever time was left over.
And I sped through everything like you wouldn't believe so I could get to that programming module.
And then I would actually stay late at school just so that I could do more.
It was really ridiculous.
That's awesome.
It's an old, old thing for me.
I was back at 12 years old doing this stuff.
That's cool.
So it really resonated with you when you figured it out and learned it, right?
Yeah.
Yeah, absolutely.
Okay.
So let's talk about what you guys are doing with 3D printing and Python.
There's all sorts of moving parts.
It sounds to me like looking over your website and looking through some of the notes you'd sent
me about what you guys are up to, that there's just all sorts of various hooks and stuff that
you're putting together, like what, web APIs or JSON, HTTP APIs that you're connecting together
with Python.
Is that right?
Yeah.
So 3D printing's kind of complicated.
It's funny in that regard because it's very much in the maker community now.
So there's all these people tinkering in their spare time doing it.
But even still, usually that simplifies things.
But even still, it is quite complicated.
And there's a lot involved to actually produce a physical object with it.
So we started out and created a system where somebody who owns a website and runs a marketplace
and just wants to sell designs can have this website, sell the designs, and our technology
is embedded in the website and allows someone to directly from the website stream a print
to their printer.
Now, obviously, I have to install a little piece of software on their local computer that talks
over the serial interface to the printer.
But the idea was to try to simplify a lot of this.
There's intellectual property controls that come into play as well.
Obviously, if you're running a website, you don't want someone to buy a design, then steal it
and turn around and sell it as their own.
And so part of our technology is to sort of separate out the model, which is the intellectual property,
from the instructions to the printer, which is what the end user is really buying so that they can end up
with a physical object that looks like the model.
So we built a system to simplify printing and realized, well, we've built all these parts and pieces
that are interesting just to makers and people who do 3D printing as a whole.
Let's separate each of them out so that people could then build applications against them.
So we ended up building a suite of web APIs that do the various parts involved in 3D printing
so that people can mix and match and use them as they want.
Yeah, that's cool.
On your website, you had a really cool, I don't know if it was a slogan or just a statement somewhere,
that you guys are building the middleware for 3D printing.
Yeah.
I mean, again, it kind of goes back to this whole maker movement of people just cobbling stuff together.
And it's funny when you start looking at, say, putting firmware on your printer,
there's a couple of fairly well-supported firmwares.
But for many years, a lot of it was, oh, download this from this forum post because some guy was tinkering with it last weekend
and he fixed these bugs and it's got some really great updates.
And someone would basically branch that.
And this was like, I mean, this was not ancient history, right?
Like this is three, four years ago.
GitHub existed, but it was still this sort of ethos of like just, you know, rip, modify, push, like stick it places, email it to your friends, which isn't bad.
It's really cool.
And I like that feel that the community has.
But at the same time, it makes it very hard for somebody new to come in and to kind of get their bearings and get going.
Yeah.
Grabbing firmware from some random user off of the internet is kind of different than, you know, actually installing trusted software, I guess.
Right.
Interesting.
So at a high level, you guys are using, you said, Flask and MicroWisgi and Python 3 to sort of put all this together.
Do you want to talk a little bit about why you chose that?
Sure.
So I've been doing Python for quite a while now, and it's really hard for anyone to do Python and to not run into sort of Django, MySQL kind of environment, especially if you were doing this six years ago, which I was.
And so I've used Django before, and it's great.
It's a really great piece of software.
But for this particular company, I felt like we had a real opportunity to start fresh.
The company's relatively young.
And I kind of looked around and looked at the tooling and thought, you know, I'd love to go with something that is really modern and a little more a la carte pieced together.
Flask was very simple and direct, and I really enjoyed it.
At the time, it was kind of best in breed, and so far I haven't found anything in Python that's necessarily better, but there's constantly new things popping up in that space in Python.
MicroWisgi I've used before at companies.
I really trust it.
It does a really good job.
Same thing with Nginx.
I mean, several years ago, it was a little bit more of a bleeding-edge choice, but now it's just like, yeah, you go Apache and, I don't know, something else.
I haven't used Apache in forever.
Or you go Nginx and MicroWisgi if you're in Python.
There's a couple alternatives, but it's just very reliable.
And I feel like you only get so many sort of innovation points that you can spend at a new company.
I really wanted to spend them on Python 3, and I tried to make everything else really just stable.
Right, yeah, I've been using MicroWisgi and Nginx to deliver all the episodes of my podcast, actually the download server and stuff, and it's been super amazing.
So, yeah, I really like it.
You said that you chose Python 3, and was that just because there was this opportunity to pick the latest and sort of reset everything as you came into this company,
or was there more to it than that?
That was certainly there, and that was definitely a component.
Part of it is that I feel like Python 3 has finally come into its own.
You know, I've been watching Python 3 for, goodness, it feels like forever, but from the initial drafts,
I was looking at some of the changes they want to make, and it's like, oh, this is really exciting.
This is really great.
It's going to be really hard to deal with this whole break in the community.
You know, I think everybody just sort of needs to do their share, and it's kind of like that pigeon.
We'll all work together, and we'll make Python 3 a reality.
So some of that is just the sense of wanting to be a part of moving things forward, right?
Like you have to reach this critical mass with Python 3 in order to get it drawing new projects to it,
and I wanted to do my part.
Part of it is also that it's finally got some features that just cannot be reasonably backported.
You know, for a while, some stuff was backported.
There was ways you could work around it, but now, like, especially async.io.
And in our company, we do a fair amount of actual streaming, and async.io is beautiful, and I really like it.
And looking through it and looking at it over, I was like, okay, we're going to do this streaming server.
Let's use something that we want to stick with that we'll be really happy with.
And I've used G-Event before, and it's fine, and some things like Tornado and stuff like that way back when.
But I just really like async.io, and I want to help build it up, and it fits our need really well.
And so we went with it.
And we were able to put something together based off of async.io really fast.
We threw together a streaming server prototype within, like, two days,
and then we started flushing it out with more of the features we needed.
And after a couple weeks, it was essentially stable.
Yeah, that's really cool.
I think async.io is definitely one of those major features that, like you said, is a legitimate reason to say,
look, we're going to choose Python 3 over Python 2 because if that's relevant to you, it really does do more in some great ways.
So what are you guys doing for deployment?
Deployment.
Yeah, that's always the question, right?
So we use Salt.
It's not just because we're based in Utah and Salt Stack is a Utah company, though we do send some love down south to our neighbors down there.
But, yeah, Salt is fantastic.
It's written in Python, which means when it comes down to debugging what's going on with deployment, we can bring all the same knowledge to bear.
We run essentially a DevOps shop.
I'm a little hesitant to throw that out there because we don't really have a choice.
My team is small and all my developers have to be able to handle everything.
And so everyone figures out how stuff gets deployed and they debug it.
So being in the same kind of stack that way helps a whole heck of a lot.
Beyond Salt for like our sort of coordination of commands and our configuration management, we actually use PIP.
So when we push a new update to some service, and we have a lot of services, we try to run essentially a microservice architecture.
We push the update into Git.
Jenkins grabs that, builds it, runs the test, ensures that it's good, all that stuff.
If it's accepted and we need to deploy it, the developer will put it in the dev environment, test it, make sure it's fine and functions as specified.
And then they tag the build, send it to Jenkins again.
It will then package it up just using setup tools, right?
Like any package you would stick in the cheese shop.
And zips that up and sticks it into an archiver.
And the archiver just is a pretend pip mirror, I guess you could say.
It's really simple.
We have this little tiny app that basically responds the way pip expects things to respond.
And then on all of our machines, we put a special config for pip saying, hey, also hit this other mirror if you're looking for anything.
And it's our internal mirror.
It's on our internal network and protecting all that stuff.
It's where all of our code lives.
And we just say pip install whatever it was.
And we have some projects that depend on one another.
And they just go through setup tools.
They're just part of the dependencies.
And our deployment system just says, hey, I want you to pip install, upgrade, you know, this system for, say, managing 3D models.
And it will look, find the newest update, install that update, download any dependencies, internal or external, get them all installed via PIP.
And then it just tells MicroWSGI to bounce the process if need be so that it updates all of its logic.
And off we go.
Like, we're PIP.
That's a really interesting way to do it.
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.
You know, it's a little crazy, but it's really cool, actually.
Especially the dependency part.
Yeah, that one was actually kind of tricky.
And it's funny because I first developed a system like this at a previous company.
And at the time, it was kind of painful because we were going through some of the growing pains of setup tools and distribute and the different packaging methods.
PIP was relatively new, but it was growing fast.
And we just decided, well, what if we try this?
Like, what if we try doing our own internal dependencies in setup tools and just let pip figure it out?
Some of our deployment people at the time were like, heretics and all that stuff.
We gave it a shot and it worked out.
And it's actually gotten much better.
Like, pip has been growing a lot recently, especially if you're in the Python 3 world.
And it's quite powerful.
I mean, there's a few things that are a little bit difficult.
We struggled with version numbers, actually, since our version numbers in Git, our version numbers went all the way through from Git, tags, all that stuff, all the way through Jenkins.
And Python 3, PIP, the latest stuff, is all very exacting about how it treats your version numbers.
And so we'll occasionally get internal conflicts or we accidentally push something to production that's not a production build because, oh, it turns out that the way our Git tag translated into a pip version ended up making it more recent than our last one on accident.
But overall, like, the system's really good.
And I kind of encourage other small businesses that are doing this, like, check this out because I've used it now at two different companies.
And it's pretty seamless.
And we're pretty happy with it.
Yeah, it actually sounds really pretty effective.
I think that's cool.
Is Docker in this world anywhere?
Are you considering Docker?
Like most modern companies, we're always considering Docker.
We're not actually using it at this point.
Right now, the feeling is that it won't buy us any advantages.
Part of that is because of the position that we're in.
We have credits with some cloud providers.
And so it's essentially free for us to spin up enormous servers and really over-provision.
And so, like, Docker can be kind of effective at eking out more bang for your buck on your resources.
We don't really need that.
And it adds a layer of complexity on top of the rest of our config management that we don't really need right now.
But we keep an eye on it because it is interesting and it's an exciting project.
And we expect that someday we probably will need it.
But first, we have to get through the growth phase.
Yeah, I kind of feel the same way.
You know, some of the stuff I was doing recently, I'm like, oh, I should probably do this with Docker and it'd be really great.
But in the end, I realized, you know, it's really a dedicated VM and it's doing one thing.
And I could just configure the VM or I could configure the Docker image and have that be the only Docker thing running, the only Docker container running.
So in the end, I just put it in and just, you know, changed it directly.
But I think you're right.
In the future, it's definitely going to make a huge difference in what we do.
I think Docker is going to be a major part of what the world has for deployment, but maybe not today for everyone.
Yeah, I had a very trusted sort of IT systems management fellow that I've worked with who's done this for many, many years.
And I talked to him about Docker once and he said the key insight you have to have at Docker is it does not get rid of the fact you have to manage a server.
Like whatever it does, it will be on top of having a server.
Now, that's not strictly true.
There's some services out there now for different cloud providers that gets rid of that constraint.
But if you keep that in mind, it kind of reminds you, oh, it's not like magic sauce that solves all of my configuration management server management needs.
Right.
It's an additional tool.
I'm very useful for what it does.
Yeah, exactly.
It doesn't it doesn't save you from everything, but it is a very cool tool.
At PyCon 2014 and to a lesser degree this year at Europython, Guido Van Rossum got up and during the keynote and basically said, I know you guys are still many of you are still on Python 2.
And some guys are moving to Python 3 like your project, but there will be no Python 2.8.
There's a great giant slide that had like two Python 2.8 and a huge like cross through it or something.
What are your thoughts on that?
That's really hard.
I agree with him.
I think you have to make the hard break.
And the irony here is if anyone was going to be pushing for Python 2.8, they should have been doing this five years ago.
Right.
And I get that a lot of people like, well, it's been five years.
That's how long they expected it to take.
And not everybody has moved over.
So obviously something was wrong.
We should have a Python 2.8.
I see it kind of the other way, which is we should have been arguing about this five years ago.
And since that's not the argument that was made, like, OK, it's either Python 3 is dead or it's not dead.
And to me, it's very much not dead.
If it were dead, OK, let's jettison it.
Let's go back to maintaining Python 2.
But it doesn't make a lot of sense to me to continue the bifurcation longer, which is all you would do.
Like the more major revisions you release of Python 2, all you're doing is extending that timeline before there's this critical mass that pulls people into Python 3.
And so, like, my attitude now is, OK, if we're talking about, you know, Python 2.8, like, what you really need to be doing is let's enumerate the constraints you have about needing to be on Python 2 and figure out how to solve those constraints for you.
Because there's so much compelling about Python 3 and so many things have moved over and support it that, to me, you really have to give me strong reasons why not to switch over rather than trying to give good reasons to backport stuff.
Yeah, I tend to agree with you on that.
I think there's a lot of interesting technical debates and conversations.
You know, I've got a million lines of Python 2 code and we just moved to 2.6 or who knows whatever.
You know, some strange thing like that, right?
And there's totally merits to that conversation.
But on a larger level, on a more philosophical level, it seems wrong to me to have this great community, some of which is focused doing their best work on Python 3, on the interpreter and these new features like AsyncIO, and then a whole other big chunk of people working professionally on this older version that's kind of disconnected in some sense.
Like, it just seems, it just seems not like a good use of the community's energy and stuff to have these two things where people are focused.
And I think you're right.
Going forward, it'd be great if it was Python 3.
Yeah, I think Guido's making the right decision by basically saying, we're just going to keep adding great things to Python 3 to make you want to be here.
It's like, rather than having two separate parties and being like, well, we should try to split food between them and music and all that stuff.
Just be like, we picked a party, let's make that party the best party it can possibly be.
And whatever happens to this other party will happen.
We're not going to worry too much about it.
I think that's kind of where Python 3 is right now.
It's like, let's put the focus on the new stuff and people will trickle over because they're going to see how awesome it is.
That's right.
And they just keep adding stuff like you say, like, hey, now our party has a hot tub.
Hey, now our party has a ski jump.
Hey, it has a cool water slide.
And eventually, like, all right, we have to go there, right?
Someday, that's probably how it's going to play out, isn't it?
Awesome.
So let's go back to your overall architecture because it sounds like you're doing a ton of stuff with Python.
Could you maybe walk us through kind of like the flow through your whole environment and all the stuff that happens there and how Python fits into that story?
Okay.
So first off, our baseline is essentially Amazon services.
We do have some other cloud providers that play in, but we're very Amazon-centric, AWS-centric as far as, like, kind of our main line goes.
So you're running Linux servers and EC2 and things like that?
Yeah.
Yeah, exactly.
Ubuntu, to be specific, for the most part.
So, yeah, we've got all these servers.
So let's say you want to print a model.
So you've got, I don't know, a new iPhone case that you want to print out maybe that has your initials on it.
Pretty exciting.
So first, you need to get that into our system.
We have a system that will take in models from partners that have marketplaces from individuals.
Anybody, essentially, you can build an account.
You send us a model.
That's going to come in through a Python API, Flask, you know, really standard, MicroWisgee, Nginx, Flask, and then SQLAlchemy, of course, talking to Postgres.
And it's going to store that record in there, and we're going to stick your model.
Basically, we're actually going to hand you back a URL that says, hey, upload your model to this URL, and it's assigned us through URL, so you don't have to go through Python.
You just send the model up there.
That way we're not having to broker all of this data that's coming in.
Amazon will do that for us.
So that then initiates a job on the back of the queue that says, hey, process this model.
There's a Python application that's pulling messages off of a queue.
It pulls down your model, analyzes it, checks to see if it's printable, gets some essential statistics about it, things like that, and then eventually we'll update a resource in the database so that you can see, okay, my model's been uploaded.
It's been ingested.
It's been analyzed.
It's good to go.
It's good to print.
All of that stuff.
We then have a couple different APIs you could use to modify the model.
Say you want to put your initials on it, change the scale, things like that.
There's different operations you might want to do to improve the print quality, that sort of thing, and that will actually cascade through the same system, reanalyze after operations and that sort of thing.
That's all done.
You can actually just stop there if you wanted.
But let's say we want to go on to actual printing.
There's another service that you would say, okay, hey, I have this printer.
It's a, I don't know, MakerBot.
No, let's not do MakerBot.
Let's say it's an Ultimaker.
You say, I have this Ultimaker printer I bought.
It's lovely.
I've got some PLA.
That's a type of plastic I want to print this with.
Here's the model that I want to use.
It's already in your service.
Here's a bunch of parameters about the print, like the wall thickness, the layer height, that sort of thing, the temperature of the nozzle so that you know what temperature the plastic's going to come out, all that stuff.
And there's a bunch of essentially like mechanical engineering, material science stuff that goes into those parameters.
And the nice thing is you could also pick very high level parameters and just say, I want quality over speed.
Figure it out.
And we'll figure it out based off of your printer and the model and things like that.
So then that also goes through, again, a Python API to handle all that, sticks it in another Postgres database.
There's another job that will go on another queue.
There's a Python process on the back end, pulls the job off the queue, pulls the model down.
It's going to load up software from different slicing engines, depending on exactly the approach and that sort of thing.
Run those processes, monitor them, push updates into a database that you could pull constantly for information about your slice.
Because slices can take a while, you know, very complex geometry with really difficult settings.
We could be talking about tens of minutes.
What's a standard time?
Most people for most prints will be on the order of like a couple minutes, really.
It's really just like the big or the really complicated stuff that will get in the tens of minutes.
So we'll finish the slicing job.
We actually have a callback API so you can tell us, hey, hit this URL endpoint when it's done so that you can integrate a service with us.
We'll tell you, hey, slicing's done.
We have instructions for your printer.
That will then get handed over to a streaming service.
Again, Python 3 using asyncio that is handling, you know, hundreds of thousands of connections at any given time for a particular server.
You will, assuming you're working on like a web page.
You could do all this with a command line, but most people do it on some sort of web page, often with one of our partners.
You'll be seeing, you know, JavaScript that's interacting with these APIs, pulling down updates and displaying the status as you go along.
You know, get to this point where it's like, okay, let's print.
You're going to, you need to download our software on your printer.
Some printers have our software built in.
Anybody who has like a laptop or desktop with the printer plugged in could download the application and run it.
That application is mostly written in Python.
There are, of course, some platform specifics as well as some encryption and stuff like that that isn't for various reasons.
Yeah.
So for the client side stuff, I was wondering, so you send them an application and a decent amount that's Python.
Are you like compiling that or composing that into an application like a .app or .exe file with something like CX Freeze?
Or how does that work?
For Windows, we're actually sending them an MSI.
For Mac, we're sending, oh goodness, what is their installer type?
I can't remember what it is for Mac, but either.
A PKG or whatever?
Yeah, yeah.
PKG.
Thank you.
Anyway, for any given platform, it's a real installer.
So it'll be properly signed and all that sort of thing, and it will walk you through a wizard and install.
The thing that it installs will end up being a binary, and that binary actually has a bootstrapping process where it unpacks itself as a bunch of PYC files and then can execute, can use those files with an interpreter that's baked in.
That interpreter has all of our dependencies.
It's got a version of Python that we know what it is so that we don't end up using whatever their installed version of Python is.
And it basically comes with everything.
So you run it, it unpacks itself, executes Python.
It's got, again, some other languages bound up in there, but mostly Python, to even do all the UI stuff.
Because we've got a little, like, sys tray icon that shows you the status of your print, that sort of thing.
This episode is brought to you by CodeShip.
CodeShip has launched organizations.
Create teams, set permissions for specific team members, and improve collaboration in your continuous delivery workflow.
Maintain centralized control over your organization's projects and teams with CodeShip's new organizations plan.
And as Talk Python listeners, you can save 20% off any premium plan for the next three months.
Just use the code TALKPYTHON, all caps, no spaces.
Check them out at CodeShip.com and tell them thanks for supporting the show on Twitter where they're at CodeShip.
That's awesome.
What UI frameworks are you using?
So for Mac, sorry, I laughed because I think for Mac it's called something like Rumps something.
It's this tiny little thing that we found.
And it's a great piece of software.
But it basically gives you – you define a class and it figures out all of the Coco bindings and stuff so that it can do a message pumping loop for you.
And it will just like – the class defines some menu items, some callbacks when those menu items get fired.
And that's it.
It's very small, very simple.
But it does exactly what we need, which is fantastic.
On Windows, goodness, I think we have something similar.
But, yeah, ultimately we're using just a couple of very, very small little toolkits that are designed only to do like a system tray icon kind of application.
There's no Windows in our application aside from a little like help blurb, like tell me about the version of this software.
But that's all.
It's just very, very minimal.
So we kept the framework very, very light.
Yeah, that's really cool.
I think that's one of the somewhat untouched frontiers of Python is proper native feeling applications.
Yeah, and it's been a bit difficult, to be honest.
It took us a while to sort out exactly how to do Mac just because we needed the Coco bindings.
And those are built into the latest versions.
But they're kind of different across different versions.
And you can't really properly virtually environment one when you're doing development.
Not easily anyways.
There's all these little complexities.
But I agree.
It's somewhat of an untouched area.
And it's really interesting because there's no reason you can't use Python much as you would, say, like C# on Windows as a high level language to just tie your UI logic together.
Yeah, definitely.
By the way, I found at least one of the rumps repositories on GitHub at JaredKS slash rumps.
Ridiculously uncomplicated OS X Python status bar apps.
Perfect, right?
Yep.
Yeah, that's exactly why we used it.
And it does exactly what we need, which is, I mean, that's the Python way, right?
That's right.
Very cool.
Okay.
I kind of short-circuited you talking about this architecture thing.
Were we getting to the end of what we got to the client side?
Or what's the story there?
Yeah, yeah.
Okay.
So the client side.
Yeah, you download this application.
All it does is mediate between the streaming server and the connection to your printer.
However we're making that connection, there's various ways it could be made.
But it does some of this UI stuff.
It does some of the streaming stuff.
And the Python is all kind of the high-level application logic, which is really nice.
We were able to take some C code that did all of this that was probably close to five to seven times as many lines of code
and compress it down into much smaller, much more easily debugged Python, which is awesome.
One of the other fun things that the client does is it will stream logging events up to our server
so that if you were trying to do a print right now, I could actually log in.
You could give me essentially a little token that would correspond to your installation.
I could watch the information coming from your printer over the wire into our data centers
so that I could actively debug with you stuff that's going on.
That's necessary because printing is just hard.
And 3D printing is a whole other level, right?
Yeah, it's a whole other dimension.
Of course, of course.
Yuck, yuck.
So anyways, that's the client application.
The last component I think that's interesting as far as Python goes is that while your print is going on,
people can opt in to a computer vision component, which is they'll mount a camera on their printer
and the camera will watch the printer as it's printing.
And we're using OpenCV on both the front end and the back end,
so on both the client-side application as well as the back end server.
And awesomely, thank you OpenCV Project for supporting Python 3 relatively recently
because we actually started on the OpenCV 3 beta when we first did this product,
trusting it would come out of beta in time for us to run it in production.
Yeah, not too long ago it did, right?
Yeah, yeah.
It was a matter of months.
It was this year.
So it was really great.
But it's a really cool piece of technology.
Anyways, we use that so that we can capture these images of the printer.
We send some data about those images up to the cloud,
and we use machine learning and computer vision on it to assess whether or not your print is going well
so that you can have these 10 and 20-hour long prints,
and it will actually text you if it looks to us like, I don't know,
so your cat jumped on the platform to get warm next to the hot plastic,
and we're trying to print on your cat.
That's not good, so we text you and let you know if your cat's there.
There's got to be a Law Cat reference in there somewhere.
I'm sure there is, but I always miss it.
Ah, that sounds really, really cool.
What's the craziest thing you've seen printed?
Sorry, I'm trying to filter through all the things that are actually okay to talk about.
Probably the craziest thing, we've gotten a surprise number of nude models.
So for whatever reason, naked people.
Interesting.
People print naked people.
Are these like little toy-sized ones?
Yeah, most of the printers that we work with can't build much more outside of,
oh, I'd say maybe 20 centimeters cubed.
So you're not doing any life-size prints.
That's probably good.
Oh, boy.
What else?
One of my favorites is people who print stuff with actual joins.
And this isn't, say, crazy,
but I think it's really interesting to people who aren't into 3D printing.
One of the first prints that I did when I joined the company was I printed out a bracelet for my wife.
And this is, of course, printed in plastic.
And it's all one object, right?
So you literally print this object, and it's rigid and hard.
And you take it off of the build platform, and then you bend it.
And you hear all of this breaking all along.
Like you just completely snapped it apart.
But all you've done is broken these really tiny bonds to keep the print as one object.
And then there are these ball and socket joints and various other sorts of joints, and they work.
And so you have this completely flexible fluid thing made out of rigid plastic that you print it all at once,
all in one object that cannot come apart unless you break it.
But it works like jewelry.
And every time I see those, I think they're amazing.
I just love them.
Yeah, that's really cool.
I have seen certain things that have been printed where you couldn't ever put it together because the way,
you know, it could be 3D printed, but it couldn't be assembled from parts, basically,
which I think is a really cool idea.
Yeah, and that actually has a lot of application into some modern industrial stuff that we've been doing lately.
Like aerospace, they have need for parts that you literally cannot machine or manufacture right now.
But 3D printing can produce these things with extremely complex internal geometry that's used for like jet engine injection type stuff
where you'll get improvements of, say, 20% in fuel economy or something like that.
Just because you have this highly advanced structure that you can analyze really in depth and get some really neat economies out of.
That's really cool.
I mean, you could make a big dent in sort of the gas consumption of the world, which, you know, could make a big difference.
That's awesome.
Where do you think 3D printing is going?
I mean, these are early days.
Yeah, my expectation is that 3D printing will follow a trajectory somewhat similar to personal computing, say, 30 years ago,
where right now we're at the very beginning.
It feels like we've essentially invented the transistor, right?
And it's going to be a little bit of time.
There's a lot of big industries getting in.
Department of Defense, aerospace, also very big because it enables them to do things they've never done before.
Kind of similar to personal computing, obviously.
And I think what will happen is a lot of these technologies will get cheaper and cheaper
and they become more and more ubiquitous.
But there will be kind of this inflection point where people realize that you don't have to manufacture things in giant warehouses
and then distribute them all over the globe via a massive logistics network.
Instead, what you'll do is you will create the objects you need at the point of use.
Now, I don't necessarily follow some people in thinking that every person will have their own personal 3D printer to make them everything they ever dreamed.
That would be pretty far out.
But I think it's very reasonable to have sort of the Kinko's model where every neighborhood has a 3D printing bureau nearby
where, you know, every couple, several weeks or what have you,
when you have a need to produce something that's personalized
or that comes through the sort of digital manufacturing environment,
you'll send them a command, they'll print it, they'll say,
hey, your thingamabob is ready, come pick it up, and you'll go pick it up.
And I think we'll see that by and large all over the world
because it's so much cheaper to just acquire the raw materials in place that you need
and then assemble them intelligently
rather than to drag raw materials all across the planet to a few focused manufacturing centers,
build the object, and then redistribute them back out the opposite direction.
Yeah, that's a really cool vision.
And I think you're right.
That sounds pretty amazing.
You know, I've been reading some books lately,
and I was talking to the authors of some, like, early, you know, not quite yet released books.
And I'm like, do you have an electronic version that I could get?
And, of course, you know, they sent me something I could put on my Kindle or whatever.
And it was just really nice that a tree didn't have to be cut down,
turned into paper, printed somewhere, and put on a truck and driven to my house.
It was just like, poof, here it is, and now it's on my Kindle.
But this is like that for everything, right?
It's amazing.
It seems realistic, though.
Yeah.
One of the other things that's kind of curious about this is most of us are familiar with mass-produced objects,
because right now that's one of the most efficient things that we have is this mass production,
which we've had for 100 years.
You know, everybody has exactly the same, you know, parts to their car,
because there's only so many manufactured these parts,
and they're just mixed and matched in slightly different ways.
But with this whole digital manufacturing thing, like, we have a print shop that we maintain here so that we can test our software for various reasons.
But, you know, one of my interns will be looking at the printer and go,
oh, you know, we're having somewhat inefficient cooling on this printer because of these various reasons.
And could we fix the ducting on this?
And we'll pull the ducting off, kind of look at it, bring up the model in a 3D modeler,
manipulate some parameters, you know, open a gap a little bit, shorten some of the length, something like that,
print it, and in, like, three or four hours, we've mounted a completely new piece of duct work that's more efficient at cooling or whatever.
And, like, we just naturally want to highly customize everything we have to deal with the particular environment that we're in.
And I think we'll see this interesting inversion where instead of having everything is mass produced,
and we try to make everything the same so that it can deal with all of these mass produced items,
we'll instead go to the opposite end where we have very intelligent tooling that can hyper-customize everything that we have.
Yeah, that's really cool.
And I think there's going to be a whole new set of sort of craftsmen that can do that customization for people rather than giant factories, right?
Exactly.
Awesome.
So people want to get started with working with you guys for 3D printing.
Maybe they want to set up a website, sell some models, and work with sort of B2C that way.
Like, what do they do?
Actually, they just reach out to us.
We keep an email address, info at authentize.com.
Reach out.
We've had all kinds of people from graduate students who are just doing studies in 3D printing that need some data to help them in their studies,
to businesses, Fortune 100 companies that want information on how they can use 3D printing to, you know, essentially mom and pop shops.
We actually have a few shops that specialize, like highly specialized, like 3D printing sex toys, say.
And they will reach out to us and say, can you help us out?
And that's what we do is we help people get 3D printing working for them.
Yeah, that's cool.
I saw you just recently had done some kind of partnership with Autodesk.
And those guys are obviously natural counterparts to what you guys are doing.
Yeah.
We're working with Autodesk to, part of the difficulty in 3D printing is the tooling, right?
You talked about new professionals that will do this design work.
Ideally, we need to, you know, push all of this interesting, professional-grade tooling out to as many people as possible, make it smarter, make it easier.
And Autodesk has some great tooling.
And so we're working together with them to try to bring more of those tools to the masses so people can do better designs and make better stuff for everyone to print.
Excellent.
Yeah, the Autodesk guys are great.
I've been out to their place.
Very cool.
How about your favorite editor?
So if you're writing code, what do you write it in?
I'm writing it in Vim.
Vim.
Okay.
Right on.
There's a ton of packages out on Python Package Index.
What one do you think maybe people don't know about that you'd like to say, hey, be sure you check out this cool thing that's out there?
Oh, this is going to sound so boring.
There's a tool for sorting your Python imports.
I'm really super weird in that long, long ago, I was involved in lots of flame wars about coding style.
And I think they scarred me in some way.
And so I actually harp on coding style a lot in my organization because in my mind, you read the thing 10 times more than you're going to write it.
Maybe even more than that if your company survives.
And so you should optimize for readability in your code.
And so I actually like all of the imports to be sorted.
I like parameters to be sorted.
I like to build little tables out of white space and code.
Anything that will make it more readable, more approachable is a good thing to me.
So like little tools like that that will sort your imports so that they're alphabetical.
Awesome.
So what's the tool?
Oh, gosh.
I pi sort something like that.
I pi sort.
I don't know.
It's one of those things that it's like you install it and you stick it in your git hook and then you never think about it.
Yeah, of course.
Very nice.
Okay.
That's awesome.
Anything else that we haven't talked about you want to let people know about or some sort of call to action?
If you have not given Python 3 a try, try it.
Like I keep going back to a lot of us will remember our original experience with Python and it feels a lot like that XKCD comic where it's like import anti-gravity and you're just like, come join us up here.
It's amazing.
My feeling for Python 3 now is that it has that same sort of gap of joy to program to Python 2 as Python 2 did to everything else back then.
So like if you have not tried it, try it.
Especially like say asyncio or, you know, any of some of the newer language developments like 3.3, 3.4, that sort of area.
Look it over.
Try it out.
It will be very hard for you to let go.
And that's part of my point.
That's awesome.
Yeah.
And then the whole type annotation thing is coming.
That's going to be a pretty interesting conversation in the community, I think.
Oh, yeah.
Yeah, I agree.
I'm watching that whole thing and I'm really excited for what it will mean.
I don't even know, which is part of what makes it so exciting.
Yeah, that's awesome.
And just, you know, to follow up on your XKCD, if anybody's not familiar with this cartoon, open up a Python REPL and type import antigravity.
It's awesome.
Eli, thanks for being on the show.
It's been really interesting.
Yeah, thanks for having me.
Yeah, you bet.
Talk to you later.
This has been another episode of Talk Python to Me.
Today's guest was Eli Ribble, and this episode has been sponsored by Hired and CodeChip.
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 and get five or more offers with salary and equity presented right up front and a special listener signing bonus of $4,000.
Check out CodeChip at CodeChip.com and thank them via Twitter where they're at CodeChip.
Don't forget the discount code for listeners.
It's easy.
Talk Python, all caps, no spaces.
You can find the links from today's show at talkpython.fm/episodes slash show slash 23.
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 feeds in the footer on the website.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song on our 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.
Having been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
you